Show HN: Serverless Postgres (github.com)
1/ It uses Fly.io[0], which can automatically pause your database after all connections are released (and start it again when new connections join).
2/ It uses Oriole[1], a Postgres extension with experimental support for S3 / Decoupled Storage[2].
3/ It uses Tigris[3], Globally Distributed S3-Compatible Object Storage. Oriole will automatically backup the data to Tigris using background workers.
I wouldn't recommend using this in production, but I think it's in a good spot to provoke some discussion and ideas. You can get it running on your own machine with the steps provided - connecting to a remote Tigris bucket (can also be an AWS S3 bucket).
[0] https://fly.io
[2] Oriole Experiemental s3: https://www.orioledb.com/docs/usage/decoupled-storage
[3] Tigris: https://www.tigrisdata.com/
63 comments
[ 3.2 ms ] story [ 132 ms ] threadOnce I have experimented with Tigris’ global data replication then it could be useful for a distributed user-base doing a lot of reads. The idea is that you can point a fresh postgres instance to the S3 bucket for read access (rather than keeping a hot standby using Postgres native replication)
This makes it feasible to build multi-tenant applications with 1-db-per-tenant. I know the same can be achieved with RLS policies or application-layer permissions, but nothing beats the peace mind (for developer and customers alike) of having tenant data in entirely separate databases. This also makes it easier to have custom schema for different subsets of users. Side note: SQLite (the OG serverless DB) also has the same benefit but is decidedly less feature-full than postgres/mysql.
Another pattern that I have seen emerging is that certain products allow end-users to create DBs on the fly as a part of their own product offering. For example, Retool (which uses Neon) allows users to create a new database in seconds, even on their free plan. I don't think this would have been possible (both cost and DX wise) if they provisioned a new Postgres cluster for each customer.
On that note, and in light of what happened with the Planetscale free plan, this would make the Supabase free offering and branching to be significantly less expensive to operate. btw: thank you for the free plan and all the amazing OSS contributions from the supabase team!!
One could easily have a single small Postgres instance for a few dollars that hosts all these small scale peanut sized toy databases and forget about it.
if your main business critical database is not doing transactions and stays idle, you should be working on bringing more transactions (sales sales sales) - not trying to save pennies on downsized postgres by moving from SSD-fast postgres to S3-slow-postgres.
I get that there are benefits to scaling up/down, but to me: Serverless is a billing model for multi-tenant services, where user is billed by service usage, not the actual underlying resource consumption. Because in multi-tenant SAAS all your tenants share the underlying infrastructure
[1] https://neon.tech / https://github.com/neondatabase/neon
[2] https://access.crunchydata.com/documentation/postgres-operat... / https://github.com/CrunchyData/postgres-operator
[3] https://www.citusdata.com / https://github.com/citusdata/citus
Crunchy Postgres for Kubernetes is great if you're running Postgres inside Kubernetes, but is more of standard Postgres than something serverless. Citus also not really serverless at all, Citus is more focused on performance scaling where things are very co-located and you're outgrowing the bounds of a single node.
It's not clear to me that kiwicopple's work horizontally scales compute, ever. It seems it has to be just one server, and if you ran multiple they'd corrupt the S3 storage.
Neon: >= 3 nodes
kiwicopple/serverless-postgres: 0..1 nodes
How tricky is it to with the S3 storage? Esp. In regards to permissions, etc.?
Thanks for sharing eh, love what you’re doing
That said, this is very much an MVP and I’m sure I’ll encounter some dragons as I push for scale or as I receive feedback from customers
It seems like it still needs memory/cpu resources locally (sized properly) to handle the returned data.
It also seems like an incredibly bad idea to use with any remote data store that charges for network traffic. ie Amazon AWS
You could easily give yourself a many thousand dollar bill for a month if you start using that backend data store in a serious way. :( :( :(
---
That being said, it's a nifty idea conceptually. Just be aware of likely operational costs if you try using it. (!)
The other tricky thing is data: there are several ways to handle this. Since Tigris has a lot of the data replication features that Postgres would traditionally handle then it looks promising. That said - it comes with tradeoffs that you point out (transfer costs) but these are also costs that you’d pay for postgres replication. I’ll try benchmark some of these costs and compare them across several implementations. At this stage I just wanted to get an MVP working: the harder stuff is still ahead
Thanks for your comment - a lot of good points
Some places define a 2nd (private) network interface for their VMs, and you can transfer data between your VMs over that private interface without cost.
Not sure if AWS does it that way though.
I don't this is the case though.
The core principle of serverless computing is that a cloud provider supplies a managed service and scales computational resources allocated to the service to meet it's computational needs.
This "serverless postgres" meets none of the items in the definition.
You mentioned AWS Lambdas. AWS allocates all computational resources when a function is invoked.
Let's face it: this was an attempt to abuse a buzzword.
The term "serverless" is broad enough that it's use here is fine.
it scales to zero and manages its own computer resources, that's a lot closer than a lot of "serverless" products ever get
Serverless architectures are provided by servers.
This is nothing new! “Serverless” is well defined and understood for years and years!
Not really,unless you want "serverless" to be meaningless.
Think about it for a second: would it make any sense to call S3 a serverless anything? And NFS? And what about gmail? Is gmail server less as well?
If the host is managing servers in a way that makes it impossible for me to even know how many servers are behind my usage of it, it's serverless.
I think this take is ridiculous and it tries to bring absurdity to a label.
Storing data on a third-party computer is not "serverless". Gmail is not a serverless messaging service. Flickr is not a serverless photo service. HN is not a serverless message board. Just because you store data on a third-party computer, that does not mean you're dealing with serverless anything.
https://en.wikipedia.org/wiki/Serverless_computing
Wikipedia defines serverless as follows:
> "Serverless computing is a cloud computing execution model in which the cloud provider allocates machine resources on demand, taking care of the servers on behalf of their customers."
What part of that definition doesn't apply to S3? Amazon themselves[1] define S3 as serverless. Your linked article also says that Cloudwatch and other AWS servers are serverless as well.
I'm sorry(?) that serverless is a broader term than you realized. It was always a somewhat absurd label.
1. https://docs.aws.amazon.com/whitepapers/latest/serverless-mu...
You can fight the common usage of a word or you can accept it. Yes, of course there is still a server involved but not one the developer has to directly manage or even think about.
If you don’t manage the server directly AND you can scale to 0 (costs and compute, aka not be forced to pay for an instance for a managed service) then it’s “serverless”.
https://github.com/akorotkov now supabase https://github.com/pashkinelfe now supabase
silicon valley isn't capitalism awesome
You use a lot of servers, you just call them resources. Your S3 storage is a server, your background workers run on a server, and your postgress, well, it doesn't run on a bike.
I hate this confabulating stuff. It's like people believing "the cloud" is an actual cloud. Couldn't we just leave this stuff to the marketing people?
I was against it too at first, but then I realized how to use it.
Even improperly tuned, it’ll take you much further than one would be led to believe from the SaaS shills.
Mentally this is the cheapest w/o all those egress costs, but I'm not sure. Combine that with we don't like managing resources outside AWS unless absolutely forced.
I really wanted this because RDS serverless v1 could do zero compute, but v2 has a minimum compute requirement.
If I can run my Postgres reliably on AWS Lambda, the costs drop to near zero for non production instances, which is where a lot of people play.
As far as I know you can’t mount a file system like EBS to Lambda, and tbh even if you could the implementation of Lambda+Postgres sounds particularly cursed.
But Lambda can't accept multiple connections to the same instance, so it's allowing multiple pg servers connect to the same data source.
A. EFS is dogs*** for this
B. The EFS protocol is NFS, so that's the question.
But on the other hand EFS blocks Lambda's JVM fast start mode that is based on Firecracker VM snapshots. Not that it matters for Postgres...