The understanding of the Neon free tier and the term, compute hours, has been something we are always trying to clear up, so it would not surprise me if the phrasing changed at some point in time, but the free tier has always allowed a user to run a database continuously as far as I remember.
I have had to correct others in our Discord server for instance too.
I went all the way back to just a few days after I started[0]. I can't find any restrictions on the free tier uptime for the primary/main database in any of the Wayback Machine snapshots of https://neon.tech/pricing.
Last year we did take a lot of heat for cold starts. Here are two blog posts which discuss how we have worked on cold starts.
I can't say this is the disconnect some are having, but it's the one I did until just now. I read "24/7 compute" and assumed that meant no cold starts. It really meant "up to 24/7 uptime but it will still scale to 0 and require cold starts."
The free tier has mentioned that auto-suspend isn't configurable on the free tier for every archive I could find on the Wayback Machine.
If you want an always on compute on the free tier, you can just setup a cron job, and every 4 minutes or so send a "SELECT 1" which will keep the database awake.
There’s a disconnect here. You are 100% technically correct. Your product’s messaging is confusing. Saying “24/7 compute” makes some people think no cold starts. Enough people in fact that you have to keep correcting them.
Thanks a lot for commenting and pointing me to the blog post. I do think I've seen it before but forgot about it. I've re-read it now and it's a great read!
From what I understand you decided to do sharding in the application code, and given the current state I think that makes total sense and I'd have probably done the same.
Part of my point with the blog post is that there is a built-in horizontal sharding solution in vanilla Postgres (partitioning + FDW), but it's currently badly lacking when it comes to cluster management, schema changes, distributed transactions, and more. If we put work into it, perhaps we tip the balance and the next successful Notion clone could choose to do it at the DB level.
> It does give a "When all you have is a hammer..." vibe to me and begs the question: why not use a system that's designed for use-cases like this and do it reliably and securely ?
(disclaimer: blog post author)
A reason would be that you want to stick to pure Postgres, for example because you want to use Postgres extensions, or prefer the liberal Postgres license.
It can also be a matter of performance, distributed transactions are necessarily slower so if almost all the time you can avoid them by connecting to a single node, which has all the data that the transaction needs, that's going to get you better performance.
Hi there! Thank you for the post and your work on pgzx!
Though it depends on the system (cockroachdb can place leaders on specific nodes to speed up local queries, it has global tables and otherwise there's always follower-reads) those are of course valid reasons.
Admittedly if you want to keep data "pinned", you're into manual placement, rather than horizontal scaling but that's nitpicking and there's pros and cons.
I do enjoy the freedom of Postgres and am hopeful that its virtually prehistoric storage-design becomes a non-issue thanks to tech such as Neon and Orioledb. The option to decouple storage would provide wonderful flexibility for solutions like yours too I think.
Xata is (like Heroku) based on Aurora, but offers database branching and has different pricing. That should be ideal for lightly-used test instances, because you only pay for storage, and 15GB are included in the free tier.
* When the pendulum has swung back from NoSQL, MySQL was in a weird place due to Oracle.
* OSS project and foundation not dominated by any particular company means that startups are willing to bet on it. In turn, these startups bring more tools, extensions, and attention to Postgres.
* The open wire protocol, with multiple existing implementations, means that if your application depends on Postgres, you will have plenty of options going forward.
* The extension ecosystem is working because extensions can do almost anything (create types, indexes, functions, etc.). And now pgrx and pgzx open up to writing extensions in Rust and Zig.
My guess was also the ease of building safe extensions along with numerous vector and time series extensions, and it's recently improved replication capabilities.
This is fair, and it's a bit embarrassing but I copied the C version from an older tutorial without looking at it critical enough. Still, the Zig version gets the arguments as normal function parameters and doesn't need to call `PG_GETARG_*`.
I notice that the c version looks like it uses memcopy as a convoluted typecast from a pointer to text (presumably a postgres typedef?) to a pointer to char (null terminated?)? Could this actually have a purpose?
Ed: I don't think PG uses c strings? Looks like memcopy might be needed for call-by-reference, return-by-value - but not really in the simple function that only walks the array?
We're referring more to the "data platform" part. What we mean by a "Postgres data platform" (and arguably it's not an widely accepted term, so take it with a grain of salt) is that you get not only Postgres, but secondary data stores around it, more tightly integrated than in a typical cloud provider:
- Elasticsearch, to which we replicate data automatically via CDC
- Blob storage for file attachments, we use S3 to store the files and Cloudflare to cache them on CDN
- (in the future) Caching
- (in the future) Time-series databases, again with automatic replication from Postgres
That said, you can use just the Postgres part, and we are very happy if you do.
Zombodb is a really cool project, but no, we don't use it.
We use logical replication and triggers to also capture schema changes with your records into an event stream. The event stream is used to send your data to Elasticsearch (and create/update the index). See: https://xata.io/blog/serverless-postgres-platform#logical-re...
Stay tuned, we are planning to open source this component as well.
It's for sure the question that a lot of people have. Initially we had more details about that in the blog post, but we didn't want it to become a "Zig vs Rust" blog post, so we kept it to a minimum.
I will expand just a little bit more here:
First, I think the fact that Rust can be a trusted language for Postgres is a huge advantage, and I am excited about it! I hope we will have the chance to use it and contribute to pgrx as well.
Postgres is not only written in C, but it has developed its own particular style of C code. For example: arena memory allocator (memory contexts), exceptions via setjmp/longjmp (ereport), single-threaded communicating via shared memory, SPI for accessing the data via SQL, etc. Some of these mechanisms kind of conflict with the way Rust likes to do things.
Because of the above, pgrx has to do harder work to expose functionality. It's possible, just a lot of work. In Zig, we can use pretty much anything directly or with small wrappers.
If you need to call into C a lot, you need to use unsafe, and that negates some of the memory safety advantages of Rust. Also, Rust unsafe code is harder to write.
It would be amazing if we could could use Zig for TLEs, and we'll look into it, but I worry it might not be possible because Zig can't guarantee memory safety in the same way that Rust can.
