4 ms·

Potentially noob question... but how does having a lambda function per route work with connection pooling for something like Postgres? Also, does ZEIT have any

Potentially noob question... but how does having a lambda function per route work with connection pooling for something like Postgres? Also, does ZEIT have any plans to offer hosted databases like Heroku and others do? That's one the biggest blockers in my mind to trying it out.

gigatexal 8y ago
Just run a sqlite db or connect to a hosted one -- though that doesn't answer your first question
nickdandakis 8y ago
I too look forward to when ZEIT revolutionize datastores. Immutable datastores with the ZEIT UX (DX?) would be incredible.
ezekg 8y ago
You would likely need to use something like PgBouncer, which sits in front of Postgres, to keep connections under control.
- ianstormtaylor 8y ago
  So to use serverless, you need to setup an extra non-serverless instance in front of your database?
  - ezekg 8y ago
    It seems so. Though, I’m in no way advocating server-less. :)
  - Rauchg 8y ago
    This is something that is only necessary for legacy databases. Modern database providers give you gateways that deal with a huge number of connections with no issues.
    - trevyn 8y ago
      Google Cloud Spanner is a counterexample. It can take close to 2 seconds to establish a server connection.
    - ezekg 8y ago
      I don't like the term "legacy database." What is a "modern" database in your eyes that is able to handle a huge number of connections?
  - setr 8y ago
    You can imagine the issue being that serverless is a stateless workload, and connection pooling is, well, stateful. Your db itself would ideally be the thing to solve that problem (its already the state-management system), but if it doesn’t, you’ll need to introduce something new to handle that state. The problem also ofc already exists when you have multiple applications (or instances) trying to talk to your db (which is why pgbouncer exists regardless of serverless), and serverless doesn’t differentiate between 1 and 1000 instances (which is why its trivially scalable). And ofc if you werent going to need sufficient scale to require something like pgbouncer... should you even be transitioning to serverless? You could replicate the same stateless organization style on your own, on a single server.
  - coder543 8y ago
    Or, you could run it on the same server that you're running your database on. If you're not running the database server yourself, is it so unimaginable that the service provider might have already configured PgBouncer on top of the database as an optional way to interface with it? Regardless, "serverless" has never meant that there are no servers involved, it just means that for the serverless pieces of your application, you don't have to concern yourself with where or how they're run, only with the application logic itself. If you want to go 100% serverless, then you're obviously going to have to choose a DBaaS that works with your connection pooling strategy, especially if that strategy is "I don't have one." Supposedly, based on comments on this thread, DynamoDB works pretty well for that scenario. Obviously Postgres doesn't scale with an increasing number of connections very well, which is why PgBouncer exists, and it works well. Finally, PgBouncer is relatively stateless. Its main pieces of state are a static config file and the pool of open connections it holds. This could be deployed in a serverless fashion, and any time it is destroyed or recreated, it would be trivially reinitialized just from the config. It doesn't have to have any attached, mutable storage.
    - vageli 8y ago
      > If you're not running the database server yourself, is it so unimaginable that the service provider might have already configured PgBouncer on top of the database as an optional way to interface with it? Are you familiar with any providers that offer this configuration? In my experience, at least AWS does not.
      - ezekg 8y ago
        Heroku has a PgBouncer setup in beta, I believe. Edit: https://devcenter.heroku.com/articles/postgres-connection-pooling https://devcenter.heroku.com/articles/postgres-connection-po...
MatthewPhillips 8y ago
That depends on the provider and the database. For AWS Lambda with DynamoDB connection pooling is handled "behind the scenes", and you don't have to worry about it. AWS supports SQL databases as well, I would assume it also is pooled for you. NOW currently doesn't have databases and tells you to use cloud DBs. So more than likely the connection is dropped when the lambda shuts down. But if you'll let me go a little bit meta, the idea of serverless is that you shouldn't even be thinking about things like connection pooling. If you just use the databases that your provide supports those types of concerns are their concerns now, not yours. In other words, if you want to pick your own tech stack then serverless is not for you (yet). If you're willing to surrender your opinions and just use what the platform provides you (if you're using AWS just use DynamoDB) then you can stop thinking about these problems and focus on your business logic.
- ianstormtaylor 8y ago
  Thank you for the detailed answer! That makes sense. Although I still find it strange... Now markets itself as preventing lock-in because it can deploy to any cloud, but to realistically use any database with it you have to lock yourself in to one of the cloud providers?
  - Aeolun 8y ago
    To expand upon the previous answer. Connection pools are still a problem. Even if your lambda drops a connection after it destroys itself, a sudden influx of visitors to your site may spawn enough lambda processes to overload your DB. What happens then is dependent on the database, but generally means that new lambdas do not get to connect. Anyhow, you don’t really want your database to magically more around regardless, so you’d be sort-of locked in to one service regardless of what you do. But postgres on one service is pretty much the same as on another, so if you wanted to migrate it would be fairly easy.
  - Rauchg 8y ago
    What the parent comment is correctly saying is that for certain databases (that are oriented around stateful connections) you might benefit from a infrastructure-level optimization. However, this is not the case for all databases. Furthermore, modern database vendors are extremely motivated to address the serverless usecase

gigatexal 8y ago

Just run a sqlite db or connect to a hosted one -- though that doesn't answer your first question

nickdandakis 8y ago

I too look forward to when ZEIT revolutionize datastores. Immutable datastores with the ZEIT UX (DX?) would be incredible.

ezekg 8y ago

You would likely need to use something like PgBouncer, which sits in front of Postgres, to keep connections under control.

ianstormtaylor 8y ago
So to use serverless, you need to setup an extra non-serverless instance in front of your database?
- ezekg 8y ago
  It seems so. Though, I’m in no way advocating server-less. :)
- Rauchg 8y ago
  This is something that is only necessary for legacy databases. Modern database providers give you gateways that deal with a huge number of connections with no issues.
  - trevyn 8y ago
    Google Cloud Spanner is a counterexample. It can take close to 2 seconds to establish a server connection.
  - ezekg 8y ago
    I don't like the term "legacy database." What is a "modern" database in your eyes that is able to handle a huge number of connections?
- setr 8y ago
  You can imagine the issue being that serverless is a stateless workload, and connection pooling is, well, stateful. Your db itself would ideally be the thing to solve that problem (its already the state-management system), but if it doesn’t, you’ll need to introduce something new to handle that state. The problem also ofc already exists when you have multiple applications (or instances) trying to talk to your db (which is why pgbouncer exists regardless of serverless), and serverless doesn’t differentiate between 1 and 1000 instances (which is why its trivially scalable). And ofc if you werent going to need sufficient scale to require something like pgbouncer... should you even be transitioning to serverless? You could replicate the same stateless organization style on your own, on a single server.
- coder543 8y ago
  Or, you could run it on the same server that you're running your database on. If you're not running the database server yourself, is it so unimaginable that the service provider might have already configured PgBouncer on top of the database as an optional way to interface with it? Regardless, "serverless" has never meant that there are no servers involved, it just means that for the serverless pieces of your application, you don't have to concern yourself with where or how they're run, only with the application logic itself. If you want to go 100% serverless, then you're obviously going to have to choose a DBaaS that works with your connection pooling strategy, especially if that strategy is "I don't have one." Supposedly, based on comments on this thread, DynamoDB works pretty well for that scenario. Obviously Postgres doesn't scale with an increasing number of connections very well, which is why PgBouncer exists, and it works well. Finally, PgBouncer is relatively stateless. Its main pieces of state are a static config file and the pool of open connections it holds. This could be deployed in a serverless fashion, and any time it is destroyed or recreated, it would be trivially reinitialized just from the config. It doesn't have to have any attached, mutable storage.
  - vageli 8y ago
    > If you're not running the database server yourself, is it so unimaginable that the service provider might have already configured PgBouncer on top of the database as an optional way to interface with it? Are you familiar with any providers that offer this configuration? In my experience, at least AWS does not.
    - ezekg 8y ago
      Heroku has a PgBouncer setup in beta, I believe. Edit: https://devcenter.heroku.com/articles/postgres-connection-pooling https://devcenter.heroku.com/articles/postgres-connection-po...

MatthewPhillips 8y ago

That depends on the provider and the database. For AWS Lambda with DynamoDB connection pooling is handled "behind the scenes", and you don't have to worry about it. AWS supports SQL databases as well, I would assume it also is pooled for you. NOW currently doesn't have databases and tells you to use cloud DBs. So more than likely the connection is dropped when the lambda shuts down. But if you'll let me go a little bit meta, the idea of serverless is that you shouldn't even be thinking about things like connection pooling. If you just use the databases that your provide supports those types of concerns are their concerns now, not yours. In other words, if you want to pick your own tech stack then serverless is not for you (yet). If you're willing to surrender your opinions and just use what the platform provides you (if you're using AWS just use DynamoDB) then you can stop thinking about these problems and focus on your business logic.

ianstormtaylor 8y ago
Thank you for the detailed answer! That makes sense. Although I still find it strange... Now markets itself as preventing lock-in because it can deploy to any cloud, but to realistically use any database with it you have to lock yourself in to one of the cloud providers?
- Aeolun 8y ago
  To expand upon the previous answer. Connection pools are still a problem. Even if your lambda drops a connection after it destroys itself, a sudden influx of visitors to your site may spawn enough lambda processes to overload your DB. What happens then is dependent on the database, but generally means that new lambdas do not get to connect. Anyhow, you don’t really want your database to magically more around regardless, so you’d be sort-of locked in to one service regardless of what you do. But postgres on one service is pretty much the same as on another, so if you wanted to migrate it would be fairly easy.
- Rauchg 8y ago
  What the parent comment is correctly saying is that for certain databases (that are oriented around stateful connections) you might benefit from a infrastructure-level optimization. However, this is not the case for all databases. Furthermore, modern database vendors are extremely motivated to address the serverless usecase