3 ms·

If I already have a postgres operator setup on Kubernetes - what additional benefits is this getting me? Right now super fast start times aren't really needed

If I already have a postgres operator setup on Kubernetes - what additional benefits is this getting me? Right now super fast start times aren't really needed since it's a database that I expect to be running for a while - ms vs 30s is fine. It's easier to setup a test database on the same machine I'm running automated tests so that may not be a good usecase either. I'm glad that they've made improvements to startup speed and size of the containers which would be good if it's open sourced, but I don't know if this is good as a paid service if you already have an easy way of setting up new clusters in k8s.

eampiart 2y ago
With Prisma Postgres, you also automatically get a connection pool and a global cache: you don't have to worry about overwhelming you db with a large number of connections, and you can add global caching to any query in just a few lines of additional code, e.g.: ``` const user = await prisma.user.findMany({ cacheStrategy: { swr: 60, ttl: 60 } }) // <--- set a cache strategy in really just a single line ``` Both of these are super important when serving users that are spread across the globe. Latencies between regions add up. If you're curious, check out https://accelerate-speed-test.prisma.io/ https://accelerate-speed-test.prisma.io/ Similarly enabled already on the db, you can subscribe to any change happening to your db, e.g. to send out welcome emails when a new user is added to the User table. Makes event-driven architectures super easy. Take a look at Pulse, which comes bundled with Prisma Postgres: prisma.io/pulse Another benefit of a managed service of course is that you don't have to worry about managing any of it. Things happen, traffic spikes, servers go down, for a lot of us, that's nice to not worry about and rather focus on building and shipping the things that make our own products and services unique. Also, in a lot of situations, provisioning something complex is just not worth it, and a quick deployment to try or test something is desired.
- ComputerGuru 2y ago
  Naive, invalidation-unaware caching is a very poor hack that can work mainly for requests that are probably not your core feature, and therefore probably not your bottleneck.

eampiart 2y ago

With Prisma Postgres, you also automatically get a connection pool and a global cache: you don't have to worry about overwhelming you db with a large number of connections, and you can add global caching to any query in just a few lines of additional code, e.g.: ``` const user = await prisma.user.findMany({ cacheStrategy: { swr: 60, ttl: 60 } }) // <--- set a cache strategy in really just a single line ``` Both of these are super important when serving users that are spread across the globe. Latencies between regions add up. If you're curious, check out https://accelerate-speed-test.prisma.io/ https://accelerate-speed-test.prisma.io/ Similarly enabled already on the db, you can subscribe to any change happening to your db, e.g. to send out welcome emails when a new user is added to the User table. Makes event-driven architectures super easy. Take a look at Pulse, which comes bundled with Prisma Postgres: prisma.io/pulse Another benefit of a managed service of course is that you don't have to worry about managing any of it. Things happen, traffic spikes, servers go down, for a lot of us, that's nice to not worry about and rather focus on building and shipping the things that make our own products and services unique. Also, in a lot of situations, provisioning something complex is just not worth it, and a quick deployment to try or test something is desired.

ComputerGuru 2y ago
Naive, invalidation-unaware caching is a very poor hack that can work mainly for requests that are probably not your core feature, and therefore probably not your bottleneck.