Hacker Newsnew | past | comments | ask | show | jobs | submit | Scorpiion's commentslogin

Looks like a nice service, it also sounds like something the SaaS companies who's pricing information you are showing would not like.

I'm curious how you look at that? Are there any legal risks for end users to share this type of information via your site? I'm thinking if the SaaS providers have some legal statements about not sharing prices (similar to how certain database providers don't allow sharing of database benchmarks).


Buyer anonymity is mission critical for us and we've taken some steps to do that like generalizing company size and industry. There's been some great feedback in this thread (thanks everybody!) about additional fuzzing we can do to protect our buyers that we'll implement.

While there may be some SaaS companies who don't like this level of transparency, we hope this actually leads to a faster sales cycle because buyers have pre-qualified themselves.


> we hope this actually leads to a faster sales cycle because buyers have pre-qualified themselves.

But by obfuscating their pricing they are able to create a marketing "lead" when you contact them that will one day evolve into a client and therefor its better for them to "pre-qualify" you.

I personally hate this model as it drives me absolutely insane to spend a month of going back and forth with a vendor, going over what i'd like to do and why, investing time in understanding their stack and product, only to find out its 2x my budget or something like they wont even consider me since its less than 10k. If you hide your pricing, make me go through an extensive process, and I let you know im trying to implement a PoC or a small entry level and you come at me with $1k/month I'm likely going to walk away and be frustrated enough to not want to do business with you ever. You've created more of a negative experience that i will tell others about than a "lead". Yet this goes against every companies thinking (even my won) so it must work on someone.


> If you hide your pricing, make me go through an extensive process, and I let you know im trying to implement a PoC or a small entry level and you come at me with $1k/month I'm likely ...

... to see if I can replicate the important parts of your SaaS for my needs, then open source it or start a competitor with a sane and transparent pricing structure to capture the rest of the market like me.


Maybe you've done this already, but from here it looks like you're publishing 5 or 6 significant digits of someone's pricing. I know if you did that with my companies product, we'd be able to identify a customer with very very high accuracy from that.

Unless "$91,132" is an indicative but somewhat randomised number, I'd strongly suggest listing that as "$91k" to reduce the information leakage about which customer gave you that number. (Same with the number of seats, although it looks like there's less entropy in this numbers at a quick glance.)


Thanks for writing this one Simon, I read it some time ago and I just wanted to say thanks and recommend it to folks browsing the comments, it's really good!


Hi bob1029, very interesting to hear about your experiences and point of view. Easy to forget the impact of how easy it's to sell an end product/service based on your selection of database (it does not always matter of course). I have thought about this as well, no one (?) will question if your app/service uses postgres but if you say sqlite I assume there will be some more questions.

Would you mind sharing some numbers of what you consider an "aggressive RPO", and what RPO number sqlite+litestream can still handle? Of course, it will depend on the use case, but if you would do a rough estimate. I think it could be helpful for a lot of readers.


For our product, I'd consider an acceptable RPO for our most stringent customer to be no more than 5 seconds of committed data loss under a catastrophic scenario (i.e. primary log writer wiped off face of planet instantly). The reason I say 5 seconds and not 0 seconds is because performance is also a feature, and we don't want to shoot our other foot off if blocking/synchronous log replication happens to get stuck for a few minutes. A region-ending event is orders of magnitude more rare than a fiber cut, so an argument can be made for async replication.

There are other bank systems that do utilize hard, synchronous replication semantics (hopefully for obvious reasons), but they can afford to sacrifice performance and availability during business hours (more than we can). We always defer to the records in these systems.

We can tolerate a few bits of work getting out of sync and needing to be recovered in the back office. Mopping up a little bit of extra trash after the apocalypse is acceptable to all involved. We cannot tolerate all users being blocked for more than a few minutes, nor can we tolerate a de-sync of aggregate system state exceeding the same. Anything beyond this and we are at risk of having to wipe all work and disrupt end customer activity to keep ops and support teams from crashing.


Thanks a lot for sharing bob1029, nice explanation and justifications, much appreciated!


Someone who understands the careful balance to strike, when data availability is actually the most important factor.

I'm in a very similar situation in my industry. Thanks for your words.


I'm not an iPhone user myself, but recently run into the fact that SwiftKey has been deprecated on iPhone when helping a friend.

Does anyone here know the details of why SwiftKey was depreciated? Did iOS change their APIs or permissions somehow or what was the reason?


Microsoft bought it years ago and essentially hasnt updated it for years. Now they're blaming iOS for canning it for good (next month).

https://www.macrumors.com/2022/09/29/microsoft-kills-off-swi...


I'm curious, what does "connector hell" mean in this context from a practical point of view?



I wonder if the decision to make all enterprise features open source was affected/influenced by the Neon release/announcement recently? The timing makes me wonder, or has this been planned for a very long time?

https://news.ycombinator.com/item?id=31753345

Either way, great news! I've been curious to try out Citus many times but the fact that many of the best parts has been closed has held me back a bit, I think it's great with more postgresql open source extention options.


Very interesting, tempted to apply to the company as this sounds very promising and fun to work on...

I'm curious about the business side of things, to give some context, some open source models that startups use today are:

1. The "open core" model, Gitlab being a good example. They try to split features that are open or closed/enterprise depending on the buyer.

2. The AGPL model, Mongodb used to do this, today a popular example is Grafana and their collection of products.

3. The Apache + cloud backend model, the core being standalone working with Apache license while building a value added managed service. I think this is what Synadia is doing with NATS.

4. The "source available" model, not really open source, but worth mentioning as it's very popular recently. Examples Mongodb, Elastic, Cochroachdb and TimescaleDB. This is often combined with open source such that some parts are open source, others source available.

With this as a reference Nikita, how would you explain how Neon thinks in regards to licensing and eventually building a healthy business? It's obvious a managed database service is the money maker, but how do you think around compeditors taking the project and building managed services without or with minimal code contributions? I'm sure you guys have thought a lot about this, would be interesting to hear some thoughts and reasoning for or against different options.

(Note: This is not meant to be an extensive explanation of these business models just a high level overview. If I have miscategorized some company above feel free to correct me in a comment.)


It's 3. Our intention is to only monetize DbaaS revenue and opensource all/most of the tech with Apache 2.0 license. It's similar to that of Databricks. Databricks over time built out photon that is proprietary. We will stay away from this ideally forever. Enduring technologies are fully open source, we see an opportunity to build a standard scalable storage tier for Postgres and maybe for other engines over time (other engines are off strategy right now).

Please do apply! we are hiring around the globe!


> Please do apply! we are hiring around the globe!

Do you expect candidates to have background in database development?

Also, any advice for someone looking to transition their career from backend to database development?


Systems >> databases for the engine. We also need fullstack or product engineers - modern DevX requires good UI. We also hire SREs and support


Tips for transitioning to database development: learn rust, start working on systems, ideally get a systems job, and optimize for being prolific. Write a lot of code


Thank you, I will follow this advice.

Neon is open source, and in Rust, I will start with that and would try to contribute.


I am very tempted to apply because it’s remote too, but do you also pay independent of the location?

Also, do you ask leet code style questions in the 1:1 rounds? More details would be appreciated


Please apply! Are cost is location adjusted. In most areas we pay 90th percentile


Interesting and glad to hear, I think it makes a lot of sense in this case!


FYI this is from 2018.

I thought it was something released recently but saw on Github that it's from 2018.


I have not used it, but my understanding is that BigQuery Omni is "BigQuery running on AWS/Azure". My understanding is that they are running Anthos on AWS (managed by Google) and they offer BigQuery as a service from that AWS infra managed by Google.

See more details here:

- https://cloud.google.com/bigquery-omni/docs/introduction

- https://cloud.google.com/bigquery-omni/docs/aws


Does anyone know if newer Philips smart TVs have this type of ads? I have one that's around 4 years old and it doesn't have it, not sure with newer ones.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: