4 ms·

Can you give a specific / concrete example of why I would want to use this instead of running a postgres server a different way (docker, binary, whatever) and h

Can you give a specific / concrete example of why I would want to use this instead of running a postgres server a different way (docker, binary, whatever) and having the tests connect to that server? I really don't understand when this would be useful.

danmur 2y ago
Me either. It's a couple hundred lines of code to make a very comprehensive fixture using the real postgres, and it supports all extensions, including exotic ones you make yourself.
lelandbatey 2y ago
These kinds of in-process/in-memory versions of dependencies take the startup time of those test from minutes/seconds to milliseconds, allowing you to run your tests vastly faster. That's a game changer for developer productivity. What's great is that your code still just depends on "postgres", so you can test against this in-memory version most of the time then occasionally (such as in CI) run that same suite but either a "real" postgres as a way to make SURE you're not missing anything.
- peter_l_downs 2y ago
  OK, that goal makes sense, thanks for explaining. For what it's worth I'm pretty sure you can do this with postgres, tmpfs, and template databases — see my project, pgtestdb [0]. I haven't done a formal perf measurement, but each test would get a fresh and migrated database in about 20ms on my local machine. The setup described runs postgres in a container for convenience, but you could probably also just run a postgres binary and store the data on a memory-backed filesystem. [0] https://github.com/peterldowns/pgtestdb https://github.com/peterldowns/pgtestdb
- stickfigure 2y ago
  You can bring "real postgres" test startup times back to milliseconds with CREATE DATABASE ... FROM TEMPLATE. Every test gets a fresh database (without having to run migration scripts) and the step takes millis.
  - CogitoCogito 2y ago
    Yeah I’d be surprised if this method weren’t just as fast. And if it’s not, would the difference just be to run the server with a ramdisk and to maybe turn off some of the durable setting to speed things up ( https://www.postgresql.org/docs/current/non-durability.html https://www.postgresql.org/docs/current/non-durability.html ).
augunrik 2y ago
I have a customer that is not allowed to run Postgres natively or docker at all (bc of security). They could use this, I guess.
- peter_l_downs 2y ago
  Wow, ok thanks that makes sense — I never thought of an environment like that.

danmur 2y ago

Me either. It's a couple hundred lines of code to make a very comprehensive fixture using the real postgres, and it supports all extensions, including exotic ones you make yourself.

lelandbatey 2y ago

These kinds of in-process/in-memory versions of dependencies take the startup time of those test from minutes/seconds to milliseconds, allowing you to run your tests vastly faster. That's a game changer for developer productivity. What's great is that your code still just depends on "postgres", so you can test against this in-memory version most of the time then occasionally (such as in CI) run that same suite but either a "real" postgres as a way to make SURE you're not missing anything.

peter_l_downs 2y ago
OK, that goal makes sense, thanks for explaining. For what it's worth I'm pretty sure you can do this with postgres, tmpfs, and template databases — see my project, pgtestdb [0]. I haven't done a formal perf measurement, but each test would get a fresh and migrated database in about 20ms on my local machine. The setup described runs postgres in a container for convenience, but you could probably also just run a postgres binary and store the data on a memory-backed filesystem. [0] https://github.com/peterldowns/pgtestdb https://github.com/peterldowns/pgtestdb
stickfigure 2y ago
You can bring "real postgres" test startup times back to milliseconds with CREATE DATABASE ... FROM TEMPLATE. Every test gets a fresh database (without having to run migration scripts) and the step takes millis.
- CogitoCogito 2y ago
  Yeah I’d be surprised if this method weren’t just as fast. And if it’s not, would the difference just be to run the server with a ramdisk and to maybe turn off some of the durable setting to speed things up ( https://www.postgresql.org/docs/current/non-durability.html https://www.postgresql.org/docs/current/non-durability.html ).

augunrik 2y ago

I have a customer that is not allowed to run Postgres natively or docker at all (bc of security). They could use this, I guess.

peter_l_downs 2y ago
Wow, ok thanks that makes sense — I never thought of an environment like that.