Serverless peeps: I love the idea of serverless. But I always get hung-up on the DB layer. How do you do DB / data storage for serverless apps?
DynamoDB seems the only real answer to me (that can be a database configured in code). Otherwise you end up with one of those AuroraDB monsters that you cant easily include database config on a framework for automatic deployment
Doesnt have to be a purist with entire stack Serverless. Depending on the use case, a managed DB (RDS or DocumentDB in case of AWS) can make more sense than forcing everything into serverless.
Find us in the forums and Community Slack for questions while you learn! is a great option
Yep. They have generous free tier limit. Enough for me.
Dang, I wish I knew more about those. I only have experience with AWS serverless.
Connection pooling is per instance. You can always configure it, no? Fundamentals remains same irrespective of where your programs are running...only thing to consider is you can only run short running operations in serverless...
Fauna is pretty swell IMO
If you can endure a little latency, we save a lot of money and get a lot of flexibility by querying Athena via Lamda: gui -> api gw -> lambda -> athena -> callback with s3 location This can take seconds or even 10`s of seconds, but is super cheap and flexible.
FaunaDB is tight with the serverless frameworks and lambda architecture. Does a good job of handling the storage concerns on behalf of your apps, no pre-provisioning, etc.
Serverless applications should be as much stateless as possible. Relying on DB connections and pooling defies disposability: serverless apps must be runnable on-demand. That means saving data is delegated to another service, a stateful one. DaaS. :-)
Ye it`s painful, but there`s some solutions in the air like stitch for mongo, plus there`s some databases built for serverless like faunadb, storage just storage services like firebase
is nice here
Through some api or api gateway.
I use Firebase.. either query directly from clients or from a serverless function
it`s pretty good, made the serverless circle complete with easy db.
Give a try
Dynamodb is best. You can go with RDS and use a proxy.
Nowadays, you have few options. Ones I know of: - FaunaDB (gql based, with proprietary query language, FQL) - Dgraph (same, DQL) - Firebase (key-value) - Begin (key-value) - PlanetScale (sql based) - AWS (headaches based)
Seems like a lot of people are just pointing to cloud DB solutions...?
There is nothing special in case of Serverless DB. However, if you can use AWS Aurora as the DB then you can use it as serverless too. If you dont have any requests coming in for a certain period of time then the compute engine can be cut off. You are only charged for storage.
I`m using for my apps. It exposes rest api on top of tables you created and they have js client library that makes easier for developers to use it
DynamoDB or Aurora with data API. Passed through few problems in the last few years and found out this is currently the best way in my opinion. Sure, build a serverless app, but generally you`ll want to pop the db on a wee server ..
you store the db connection outside the closure and share it with invocations. If you`re concerned with backpressure theres other strategies. Writing to a queue and not right to the db isn`t bad.
1. It`s definitely not relational database by default 2. Consider data access patterns 3. Imagine rapid scaling up and down and what might happen to the data layer 4. Look at why DynamoDB was created 5. Use that or similar
Hi Spencer - Prisma was mentioned a few times, so thought I`d jump in. Connection pooling is a real issue, but pg_bouncer solves it well if you are okay with running that instance yourself. Some of our users have experimented with the Aurora Data API, but it doesn`t work well.
Storage and Computing. db is for storage, serverless is for computing.
My first preference for Serverless would be DynamoDB. For SQL, using something like Aurora Serverless or Aurora with autoscaling and avoiding long-running transactions should work fine.
There are many options. - AWS Aurora Serverless - FaunaDB - Mongo Atlas etc. First step is to understand is SQL or NoSQL is your thing. Because if you`ve built an app you probably have used either. Or you want to build outside them abit - FQL
Weve been using Firestore in production for a few months and so far its gone pretty well
Postgres with Cloud SQL from is a nice solution
No mention of !
mentioned this too, but if connection limits are your issue, you want Firestore. Soft limit of 1M concurrent connections, and automatic horizontal scalability across multiple regions.
You can never go wrong with using Firebase is pretty straightforward and the integration between cloud functions and Realtime database or Firestore is seamless. Price => vendor lock in with Google.
The industry pattern is to go with a managed instance as far as I know. I see you mentioning connection pool limits in other comments. Just use firestore and make sure to await (or equivalent) your writes and they`ll be sure to persist.
at the startup I`m working at we just started using RDS proxy. I`m not an expert on the details but it`s worked fine until now. Best DX would be dynamodb
Cosmos DB has serverless. I work on the team. DM me if you`d like a quick tour or to just learn more.
Function Apps + Cosmos is an amazingly simple integration for a wide variety of use cases, weve used it extensively
Communicate with your DB using a GraphQL layer like or use AWS Dynamo BD.
Connection pooling is a big concern. Although all major database hosting providers now support connection pooling. Also if you are on Postgre, you can use PgBouncer to implement easy pooling.
I`ve been doing Aurora Postgres Serverless with Data API. I found this lightweight wrapper to be helpful in my lambda functions: If you`re on AWS you can push your results on SQS.
DynamoDB with a healthy dash of dynaglue to make it easier to use :-) But folks RDS is pretty well supported these days if you are committed to SQL
Did not know about the restrictions. I built an app using serverless functions and MongoDB and it works. is where its at
I used DynamoDb, but it was quite a brain melt to get used to it. Called it from Lambda[Node], from Api Gateway. [ ps now I`ve embraced NoCode, so I love not thinking too much about db choices]
Its all serverless. All the way down. At least until you hit turtles. Then its turtles.
The hardest thing is decoupling the idea of pools. I would reach for a DB that has an API layer to alleviate the whole pooling notion. DynamoDB or Fauna are great choices.
For aws you got dynamo Db
DynamoDB or Aurora depending on the use case
If youre already cool with ditching the server, maybe youd be interested in ditching the DB too Check out the JS libraries that let you use BitcoinSV as an always on, always up NoSQL DB.
dynamodb i love it
Checkout Honestly I settled with CMS supporting graphql instead Serverless with a db layer will suck so many hours of development If your focus is front end, intergration, nodejs functions for feature, Id go for vercel, a cms like Sanity or Contenful and start building
For rapid deploy incl. auth, Id recommend the new .. it is very promising.. not yet fully featured but great for smaller, less complex projects. is great too but you may get lost in FQL and their UDFs. Anything with a large schema go with 1 click Netlify site with functions with faunaDB instance all wired up Click deploy to Netlify button to give it a spin
To handle DB connection limit! I prefer to use queue based design.
Active server and server less (still a server) look and feel quite the same when it comes to a data access layer. Youre establishing a connection, sending a request, and receiving a data payload. Its the same for SQL and NoSQL.
Previously using and now I saw other vendors mentioned, but didn`t see firebase. Look at that too. I`ve had success on that platform as well as the others mentioned
DynamoDB, it`s the best part of serverless! You`re gonna love it. You just make an API call, and you`re data`s saved. Make another one, and you have your data. No CPU monitoring. AND you can spin up copies of your database for, say, your dev branches for basically no cost.
for me is a great experience.
On AWS I use RDS or Aurora (not Aurora serverless) as a shared database and virtually isolate my domains in Postgres Schemas. This makes it easy to eventually migrate to DynamoDB when you schema is solidified and you`re comfortable with DynamoDB, Migrate each table at a time.
Consider and see the docs on connection pooling is my go to together with RWs use of for migrations and lots of deploy options or or to name few
At we`re just starting our beta for Akka Serverless which brings together functions and database into a single package. I`d be more than happy to show you and get your feedback on it!
is excellent for serverless DB - and if you need serverless message queues and/or cronjobs / delayed events, I`m working on something that you`ll be interested in!
AWS has a proxy layer for RDS which acts as a pool but the setup is painful
I usually love storing directly to a document based db such as dyanmo but, definitely want to try out some new techniques.
FaunaDB, built for the Serverless world. (I hesitated between Supabase and FaunaDB, both look good)
Is a pretty common problem! Im researching all kinds of dbs and Serverless lately! And doing experiments on weekends! All responses here will help me too! Thanks! Im using for my API, just like any other backend.
If you`re using AWS RDS they also have RDS Proxy which can help when your lambdas spawn too many connections
DynamoDB. It`s fairly straightforward with and if that`s a bit intense I reccommend trying with begin/data which reduces dynamo to get/set/destroy
AWS RDS Aurora MySQL Serverless, with Data API. The api uses the aws cli to perform queries. There is a 1mb limit on query results and a hard 1k-requests-per-second throttle , but its an amazing resource for 99% of startups who arent serving viral in cached content.
A great option is They are API first and optimized for serverless :)
Well the first problem is the misnomer of serverless. Clearly it isn`t. But in the vein of that, you get a serverless data option where someone else is managing the underlying servers. Poof, you`re fully serverless, but you`re still using a database as such.
you don`t need to worry about connection pools, you can wrap an API around it or use it directly from your client with FQL or GraphQL (I prefer GraphQL personally).
Honestly, same boat. I know stuff like Dynamo exists but its just kinda hard to get into. Are you more into SQL or NoSQL? I think there are quite a few serverless DBs out there, and to name a few.
Not sure if there is an equivalent solution for Mongo, but pg_bouncer is a solid option. You can always setup a worker with a queue for DB access to avoid concurrents
Firestore for user data and other similar use cases.
Always (always, always) AWS Lambda + DynamoDB, connection pool limits are not a thing/issue with DynamoDB.
Use supabase or heroku Connection pooling is built into supabase and heroku as well.
We use AWS Lambda with MongoDb Atlas at We follow the Atlas best practices and cache the connection outside the handler function. Whilst the function is hot, the connection is reused. Serverless functions should be used in such a way that it finishes processing quick and exists in couple of seconds. This applies to DB as well so that other functions does not wait for long in the pool to establish connections.
Totally agree - I have tried a lot of different options and do not love any of them.
With that being said. That new db built on mysql with per environment deploys sounds awesome
Have someone else deal with it, or just continue to scale the DB higher
I havent had a large enough app to worry too much. But cloud sql supports 4,000 max. And they also let you set a max number of concurrent serverless function invocations. So I figure, by the time I would have that many invocations concurrently, Im making enough to
supabase really simplifies this for me in my nextjs apps
for rds with rds proxy aurora no need dynamodb no need
Feel free to ping me offline, if you need any help on this ;) here you can find more detailed information about Connection pooler with Pg bouncer: Whats the reason for switching? Are you having issues with hosting a long-running server on Render?
Ohhh interesting. I wonder if you could take a microservice approach and have the functions request data from a DB service without adding too much latency
You can use pg_bouncer to re-use open connections across serverless function requests. I havent actually done this yet though. I kind of just accepted that Ill be running a server for now, even though I would like to be fully serverless.
For postgres, i usually recommend connection pooler, if youre seeing high number of connections established against the database or therere short live connections from application side, would recommend to use pgbouncer.
I use serverless Azure Cosmos DB. It has several ways to interact with it SQL API, Graph, Mongo etc. The serverless pricing is great and has geo redundancy at a click. I`m a big fan! is my new favorite!
I am quite new to serverless, and for my current side-project, I have picked Easy to start with, and the community is very helpful. It took me a bit of time to understand the concept, especially security, but it all worked out great.
I`m new to serverless. This was also the part I got stuck on. I ended up moving ahead with and so far it`s worked fairly well. Of course I`ve made several newb mistakes and also still don`t have a solution for migrations in place.
I personally use dynamodb. it`s a solid choice for serverless architectures, however you must spend some time to learn how to use it. alternatively, if you`re on aws, you can use aurora serverless. if you want to keep your SQL setup, you`ll need to be careful with pooling.
Firestore is actually awesome and plays super nice with Firebase cloud functions
We use Firestore, but you can use whatever you want. DBs can be serverless too.
If youre using azure platform, let me know i can help you.
I always use an external DB provider. DO for Postgres, Mongo Atlas for MongoDB etc
Why would serverless work different regarding a db?
We mostly use Dynamo for our regular lambdas, which is a whole bunch of trade offs but works well in that use case. We have some occasional lambdas that just connect to the prod Mongo instance too, but they dont run at the scale where you need to think about connection pools
Prisma migrate. Have a staging server and production. All schema changes are additive, never removing or doing breaking changes. Every deploy runs the migrate command. Same approach to graphql apis where its versionless and never break the schema (only add)
Nothing really changes for db you can connect to a SQL or nosql service like dynamodb, aurora, or RDS. you just change the connection string.
What platform are you using?
