DEV Community: Bob Bass

From PGlite to Production Postgres

Bob Bass — Wed, 26 Aug 2026 11:54:00 +0000

There is a specific moment in a project's life where an embedded database stops being enough. Usually it arrives without warning. Someone else wants to use the thing. Or you deploy a server component and it needs to read the same rows the browser has been writing. Or you want a cron job, a webhook, a second device, a teammate. The database that has been living inside your app now needs an address.

If your prototype was built on PGlite, the good news is that this is one of the easiest graduations in the business, because you were already running Postgres. Not something Postgres-shaped. Actual Postgres, compiled to WebAssembly, running in process.

This originally ran on the Layerbase blog. The timing is why everyone is talking about this right now. On August 11, 2026, Electric joined the Neon team inside Databricks, and the number in that post is the one worth staring at: PGlite went from 1 million to 13 million weekly downloads in a year. The thesis behind it is that coding agents are driving the cost of building software toward zero, so there is about to be an enormous number of small applications. A lot of those start embedded, because embedded is the fastest way to get something working. Some fraction of them will get real users. That fraction needs this guide.

Why PGlite graduates cleanly

Most embedded databases make you pay on the way out. You wrote against SQLite's type affinity or a document store's query language, and moving to Postgres means rewriting a schema, rewriting queries, and rediscovering every place your code assumed the old engine's behavior.

PGlite does not have that problem, and it is worth being precise about why. It is not a reimplementation of Postgres and it is not Postgres running inside an emulated Linux VM. As the project puts it, it is "simply Postgres in WASM," using Postgres' own single-user mode with a custom I/O path into JavaScript. Your CREATE TABLE statements are Postgres DDL. Your queries are Postgres SQL. Your SERIAL columns, your jsonb, your constraints and defaults all mean exactly what they mean on a server.

So the migration is a dump and a restore. That is the entire shape of it.

Step 1: dump the PGlite database

PGlite ships a companion package that runs the real pg_dump against a live PGlite instance. Install it alongside PGlite:

npm install @electric-sql/pglite @electric-sql/pglite-tools

pgDump takes your PGlite instance and hands back a File you can read as text:

import { PGlite } from '@electric-sql/pglite'
import { pgDump } from '@electric-sql/pglite-tools/pg_dump'
import { writeFileSync } from 'node:fs'

const pg = await PGlite.create('./pgdata')

const dump = await pgDump({ pg })
writeFileSync('pglite-dump.sql', await dump.text())

That is the whole step in Node. The dump is standard SQL: schema, then data. pgDump appends --inserts by default, so the data comes back as ordinary INSERT statements rather than COPY blocks, which makes the file restorable into any compatible PostgreSQL server. Compatible is doing some work in that sentence: check that the target's major version is not older than the one PGlite was built on, and that any extension your schema leans on exists there too.

If your data lives in the browser instead of on disk, the same call works against a browser-backed instance. Open the database at whatever data directory you have been using, idb://my-app for IndexedDB, run pgDump, and download the returned File instead of writing it:

const pg = await PGlite.create('idb://my-app')
const dump = await pgDump({ pg })

const url = URL.createObjectURL(dump)
Object.assign(document.createElement('a'), {
  href: url,
  download: 'pglite-dump.sql',
}).click()

If you kept the data in OPFS at opfs-ahp://my-app, the same call works, but that filesystem only runs inside a Web Worker, and it does not work in Safari at all: a Postgres install opens more sync access handles than Safari allows. Run the dump from the worker that owns the database.

Two things worth knowing before you move on. pgDump runs DEALLOCATE ALL on the connection when it finishes, so any prepared statements you were holding are gone. And the dump does not carry your session search_path, so if you were relying on a non-default one, note what it was before you dump and set it on the other side.

Open the file. It is human-readable SQL, and reading it is a good sanity check that everything you expected made it in.

Step 2: create a hosted Postgres

Two paths, both real. Through the dashboard, pick Postgres at layerbase.com/create/postgresql, name it, and you have a database in under a minute with a connection string on the detail page.

From a terminal, the Layerbase CLI does the same thing. Cloud commands authenticate with a personal API key from your dashboard settings, which is also what makes this scriptable later:

npm i -g layerbase
export LAYERBASE_API_KEY=sk_...

lbase cloud create my-app --engine postgresql
lbase cloud connection-string my-app

postgresql://layerbase:<password>@your-host.cloud.layerbase.dev:5432/my-app?sslmode=require

The free tier covers this: two databases, 5 GB, one branch each, no credit card. That is deliberate, and I will come back to why it stays that way.

Step 3: restore the dump

You have a SQL file and a connection string, so this is the standard Postgres move:

psql -X -v ON_ERROR_STOP=1 "$DATABASE_URL" -f pglite-dump.sql

-X skips your .psqlrc so nothing you set up locally leaks into the restore, and ON_ERROR_STOP=1 halts on the first problem rather than ploughing through and leaving you guessing. On a fresh database there usually is not a first problem, because the dump was produced by pg_dump from a Postgres that agrees with the one receiving it. If it does stop partway, start clean: drop and recreate the database, or delete it in the dashboard and make another, rather than re-running the file over a half-loaded schema.

If you would rather not have psql installed, the CLI can push the file for you with lbase import pglite-dump.sql --target my-app --yes, and the query console in the dashboard will run statements against the database directly from the browser.

Step 4: swap the connection string

This is the step people brace for and it is anticlimactic. Wherever you had:

const pg = await PGlite.create('./pgdata')

you now have a normal Postgres client pointed at an environment variable:

import { Pool } from 'pg'

const pool = new Pool({ connectionString: process.env.DATABASE_URL })

Your queries do not change. If you were using an ORM, its Postgres dialect was already the dialect you were using. What changes is that the database is now a thing on the network with credentials and TLS, which is exactly the property you needed when you started this.

If you are on Node, you will likely see the sslmode=require treated as verify-full warning. Swap require for verify-full in the URL. The write-up is here.

What you actually get on the other side

Graduating buys you the operational layer an embedded database has no way to give you.

Backups you did not have to think about. Every destructive path takes a backup first, deletion is refused if a final backup cannot be secured, and the most recent backup is never pruned. That applies on the free tier, not just paid ones.

Branching. Fork a writable copy of the database before a risky migration, run it, and throw the branch away if it goes badly. It works on 16 engines, Postgres among them. Details in the branching docs.

A query console, so debugging production data does not require a psql session and a laptop.

Sleep and wake, instead of a bill. Free databases sleep after 60 idle minutes and wake when you reconnect, which takes a few seconds and looks like a slow first connection rather than an error. No keep-alive cron job, no dashboard button, no restore flow. That mechanic is the whole reason the free tier can stay: a sleeping database holds no RAM and no CPU, so we are not carrying a fleet of abandoned side projects at a loss. I wrote out the full economics in the free tier that stays.

Postgres is one of 18 engines on Layerbase Cloud, which matters mostly for the next thing you add. When the app that outgrew PGlite wants a cache or a search index, it goes on the same account instead of a new vendor.

The honest fork in the road

Not every prototype should graduate, and I would rather say that plainly than pretend otherwise.

If your app is genuinely local-first, if the data belongs to the person using it and never needs to be reachable from a server, PGlite is the right answer and you should keep it. That is the case it was built for, and it is very good at it. Same if you are using it as a test fixture or a sandbox: an in-process Postgres that starts in milliseconds is hard to beat. And if what you want is a real Postgres server on your own machine rather than a hosted one, the Layerbase CLI runs those locally too, no Docker required.

The fork is not about scale or seriousness. It is one question: does something other than this one client need to read or write these rows? The day the answer becomes yes, you have a ten-minute job and no rewrite, because you picked a database that was Postgres the whole time.

Create a Postgres database and run the dump. If you want the background on the engine itself first, the PostgreSQL page covers what we run and how, and connecting to a database covers the client side in more depth.

version `GLIBC_2.38' not found, and the release check that stops it

Bob Bass — Tue, 25 Aug 2026 14:02:00 +0000

./qdrant: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found

If you have seen that, you already know the shape of the problem: a binary that runs perfectly on the machine that built it, and cannot start at all on a slightly older one. What is less obvious is that you can hit it three completely different ways without changing a line of your own code, and that none of the usual release gates will catch any of them.

This originally ran on the Layerbase blog. We ship prebuilt binaries for a couple of dozen database engines across five platforms. In one month we got bitten three times.

Why glibc breaks in one direction only

glibc symbols are versioned. When a binary uses a function, the linker records the minimum glibc version that provides the exact behavior it compiled against, as a symbol version like GLIBC_2.38. At startup the dynamic linker checks those requirements against the glibc actually installed.

The compatibility runs one way. A binary built on an older glibc runs on newer systems, because newer glibc keeps old symbol versions around. A binary built on a newer glibc does not run on older systems, because the symbol version it names simply does not exist there.

So your build machine's glibc becomes a floor on every machine that can run your output. Build on Ubuntu 24.04 (glibc 2.39) and you have silently dropped Ubuntu 22.04 (glibc 2.35), which is still an LTS release plenty of people run.

The failure is total, not partial. The process never reaches main. There is no graceful degradation and no useful diagnostic beyond the line above.

Three ways it reaches you

1. The upstream project's own binary requires it. Official SQLite binaries for Linux require GLIBC 2.38 or newer. Not a mistake on their part, just a build environment choice, and it makes them unusable on Ubuntu 22.04 and older. Our fix was to stop shipping the official Linux binary and build SQLite from the amalgamation source inside ubuntu:20.04, which gives a 2.31 floor. Nothing about the resulting binary is worse; it simply has a lower floor.

2. The upstream project changes their build between releases. Qdrant 1.16.3's linux-gnu tarball needed only GLIBC_2.34. Version 1.18.3 of the same asset needed GLIBC_2.38. No announcement, no major version bump, and the only visible symptom was that half our test matrix went red: Ubuntu 24.04 (glibc 2.39) was fine, Ubuntu 22.04 was not.

The fix there was different. Qdrant also publishes a linux-musl tarball, which is statically linked and references no glibc symbols at all. Static binaries pass this problem trivially, which is worth remembering as an option whenever a project offers both.

3. Your base image moves underneath you. This is the sneakiest one. We extracted CouchDB from the official couchdb Docker image, taking /opt/couchdb but not the system libraries the bundled Erlang runtime links against. That image tracks Debian stable, and at 3.5.2 it moved from bookworm to trixie.

So the extracted tree silently inherited a different distro's libraries. On Ubuntu 22.04 the Erlang VM needed GLIBC_2.38 and never started. On Ubuntu 24.04 it started and then died differently, because crypto.so needed OPENSSL_3.4.0:

{application_start_failure,config,{undef,{crypto,info_fips,[]}}}

Two distinct failures from one upstream base-image bump. And because we only logged "start timeout, then ECONNREFUSED," neither cause was visible until someone read the engine's own log.

That one was fixed by building from the project's apt repository pinned to jammy inside ubuntu:22.04, so the toolchain is pinned to our oldest supported target rather than to whatever a third party's base image happens to be this month.

The part worth stealing: check what your artifacts actually require

All three shipped green. Every existing gate passed. They only failed two repositories downstream, in a consumer's Ubuntu 22.04 CI, because nothing in the release pipeline ever looked at what the binaries required.

That is the real bug. The individual glibc problems are ordinary; the absence of a check is what let them all reach users.

The check is not complicated. For every Linux archive in a release, extract it, find every ELF file, read the highest GLIBC_x.y.z symbol version referenced, and fail if anything exceeds your declared floor:

# highest glibc symbol version a single ELF file requires
readelf -V "$file" 2>/dev/null \
  | grep -o 'GLIBC_[0-9.]*' \
  | sort -V \
  | tail -1

objdump -T works as a fallback where readelf is unavailable. A few details make the difference between a check that works and one people disable:

Find ELF files by magic bytes, not by extension. Binaries in these archives are often extensionless, and plenty of .so files live in subdirectories you did not expect.

Skip non-ELF payloads gracefully. JVM engines ship jars with nothing to inspect. If your check errors on those, it becomes noise and gets bypassed.

Static binaries pass trivially. musl, Go, and Zig builds reference no glibc symbols, so they return nothing and pass. That is correct, not a gap.

Put the floor in one constant. Ours is GLIBC_FLOOR="2.35", matching Ubuntu 22.04, the oldest target we support and the base image our build containers use. One constant, one place to change it when the support window moves.

Skip macOS and Windows archives. There is no glibc there, and trying to inspect them produces confusing failures.

We wired that into every release workflow. It would have caught all three incidents above at build time rather than in someone else's CI.

The general version

Anywhere you redistribute a compiled artifact, the build environment is part of the artifact's contract, and it is a part nobody declares. It gets inherited from a base image, from a CI runner's default, or from whatever a third party built their release on.

So state your floor explicitly, build on it deliberately, and add a gate that reads the requirement out of the artifact rather than trusting that it matches. The check costs seconds and it fails loudly in the one place you can still do something about it.

If you only take one thing: the glibc version of your build machine is a compatibility decision you are making whether or not you know it.

We run this check across every engine we ship at Layerbase, because "works on the build machine" turned out to be a guarantee about nothing at all. The full write-up, including the three incidents, is on the Layerbase blog.

MongoDB vs FerretDB on the same hardware: the benchmark, and what we had to fix to run it fairly

Bob Bass — Sat, 22 Aug 2026 12:03:00 +0000

A prospect evaluating us for a latency-sensitive, write-heavy workload asked a fair question: how does FerretDB actually compare to the MongoDB they run today? I did not have an honest answer. What I had was other people's numbers, mostly a well-known third-party run at 1 billion records where MongoDB wins writes by a wide margin. That result is real and I am not going to argue with it. It also is not the question I was asked. The prospect is not running a billion records on a benchmark rig. They are running a working set on a box they pay a flat monthly rate for.

This originally ran on the Layerbase blog. We measured on our own hardware. The benchmark then spent most of its time telling me about us instead of about MongoDB, which is why this post exists.

Two of the findings were misconfigurations in our fleet that had been quietly costing every customer performance. Three more were bugs in the benchmark harness itself, which meant the first full round of numbers was garbage and had to be thrown away. The MongoDB comparison, which is what I set out to get, ended up being the fourth most interesting thing I learned.

If you want the background on what FerretDB is, the MongoDB vs FerretDB comparison covers the wire protocol, the feature gaps, and the licensing difference. This post is only about how the two perform on one specific box.

The setup

Everything below ran on the same hardware profile: an OVH d2-8 instance, 4 vCPU and 8 GB of RAM, Debian 13, ZFS 2.3.2 with the ARC capped at 2 GiB. That is not a benchmark rig chosen to look good. It is the exact flavor behind our Dedicated 8GB preset at $65 a month, which is what a customer with this workload would actually buy.

YCSB 0.18.0-SNAPSHOT
10 million records loaded, 1 million operations per run, 600 second cap per run
Workload C (100% read), workload B (95% read / 5% update), workload A (50% read / 50% update)
16, 64 and 256 client threads
Write concern 1 on both sides
MongoDB 8.0.29 and FerretDB 2.7, one arm per box, boxes torn down afterward

A 10 million record YCSB dataset is roughly a 10 GiB working set. On an 8 GB box, that is deliberate. This profile does not fit in memory, so storage layout matters, and storage layout is exactly what I wanted to see.

The first bug was ours: 128K records over 8K pages

FerretDB stores documents as JSONB in PostgreSQL. PostgreSQL writes in 8 KiB pages. Our ZFS dataset that holds user data, tank/users, was sitting on the ZFS default recordsize of 128K.

An 8 KiB page write into a 128 KiB record is a read-modify-write of the whole 128 KiB record. Every dirty page. On every box in the fleet.

This is not an exotic finding. It is the first line of every "PostgreSQL on ZFS" tuning guide written in the last decade. We had simply never checked, because nothing was on fire. No customer had complained, no alert had fired, no dashboard was red. It was not hurting anyone visibly. It was just leaving a large multiple of read throughput on the floor, silently, for everyone.

The second bug was also ours: PostgreSQL on stock memory

While I was in there, I looked at the PostgreSQL configuration the FerretDB backend was running with. It was stock. shared_buffers at 128MB, which is the compiled-in default, on a box with 8 GB of RAM.

Same category of problem as the first: nothing broken, nothing alerting, just a database told to use a rounding error's worth of the memory it had been given.

Neither of these was a bug in the sense of a crash or a wrong answer. They were both defaults nobody had revisited, which is the kind of thing a benchmark is unreasonably good at finding, because a benchmark is the only workload that complains.

Then the harness lied to us

Round one finished. The numbers looked odd. Throughput barely moved between 16, 64 and 256 threads, which is not how a client-server database behaves unless something is wrong.

Three things were wrong.

YCSB silently ignored our thread count. We were passing -p threads=64. The property YCSB actually reads is threadcount. An unknown property is not an error in YCSB and produces no warning, so every single round-one run executed at the default: one thread. Every number in that round measured single-threaded performance while labeled otherwise.

The driver capped the connection pool at 100. The YCSB MongoDB binding uses the Java driver's default maxPoolSize of 100 unless you set mongodb.maxconnections. So the 256-thread rows are not 256 concurrent connections. They are 256 client threads queuing over roughly 100 connections. The cap applies to every arm equally, so the comparison stands, but "256" is a client-thread count and not a concurrency claim.

The CSV parser matched nothing. Our result extractor ran grep -E 'Throughput(ops/sec)' over the YCSB output. In an extended regex, those parentheses are a capture group, not literal characters, so the pattern searches for Throughputops/sec, which appears in no file we have ever generated.

Round one's relative deltas survived all of this, because every arm was broken identically. Its absolute numbers did not survive, and absolute numbers are the entire point of publishing a benchmark. We deleted them and re-ran everything on a corrected harness. Every number below is from the corrected generation.

The ablation

Once I knew the recordsize and the memory settings were both wrong, I could not just fix both and report the combined win. Two changes and one result tells you nothing about which change did the work.

So we ran an ablation: five fresh boxes, one variable each, identical loads. OVH bills these by the hour, so the whole thing cost about $5.55.

16K recordsize alone was worth 3.7x to 4.3x over stock on reads at real concurrency. The single largest lever, and it is a one-line dataset property.
Memory tuning alone was worth roughly 1.0x on reads. Not a typo. On its own, against 128K records, it was actively negative at 256 threads, because more dirty buffers over a 16x write amplification factor produced checkpoint storms rather than throughput. This is the finding I would have gotten wrong if I had shipped both changes together and taken credit for the sum.
Both together, which is the profile we are now making the default, gave 4.0x to 4.3x on reads and 2.4x to 3.0x on the 50/50 workload against the ablation's own control box, the arm among the five that changed nothing and kept 128K records with stock PostgreSQL memory settings. That control is not the same box as the "FerretDB stock" column in the tables below, which was built a day earlier and ran slower on the 50/50 mix; measured against that column instead, the same tuned arm computes 3.6x to 4.3x. Both comparisons are on our hardware with the same 10 million record working set, and the cross-box caveat in footnote 4 is exactly why they differ. Update p99 on the stock arm sat around 2 seconds and collapsed to somewhere between 0.1 and 0.8 seconds.
Relaxed commit durability owned writes: 4.3x to 5.3x over stock, with update p99 between 19 and 281 ms. This one is an explicit customer opt-in and will never be a default, because it trades the last instant of acknowledged writes if the machine loses power. That is a decision a customer gets to make about their own data, not one we make for them.

One oddity I cannot explain and am recording anyway: the relaxed-durability profile is about 0.9x the tuned default on pure reads. Reproducible across runs, no theory that survives contact with the data. It is why we label that opt-in as write-workload-only rather than as a general speed setting.

There was also a superseded arm: an earlier box using an 8K recordsize measured consistently below the 16K arms on all three workloads. 16K beat 8K, which is not what I expected going in, and is why the ablation existed.

The numbers

All of the following is the corrected harness generation, same hardware profile on both sides. Columns are MongoDB 8.0.29 stock, FerretDB 2.7 on our old stock configuration, FerretDB on the new tuned default with durability intact, and FerretDB with the relaxed-durability opt-in.

Workload C, 100% read, ops/sec

Threads	MongoDB	FerretDB stock	FerretDB tuned default	FerretDB durability opt-in
16	755	879	3,888	3,458
64	756	946	4,065	3,635
256 (pool)	753	952	3,851	3,522

Tuned default versus MongoDB: 5.1x to 5.4x.

Workload B, 95% read / 5% update, ops/sec

Threads	MongoDB	FerretDB stock	FerretDB tuned default	FerretDB durability opt-in
16	700	884	3,611	3,624
64	750	931	3,919	3,767
256 (pool)	712	933	3,526	3,386

Tuned default versus MongoDB: 5.0x to 5.2x.

Workload A, 50% read / 50% update, ops/sec

Threads	MongoDB	FerretDB stock	FerretDB tuned default	FerretDB durability opt-in
16	491	412	1,631	2,916
64	464	491	1,752	3,020
256 (pool)	465	368	1,586	2,795

Tuned default versus MongoDB: 3.3x to 3.8x. Durability opt-in versus MongoDB: 5.9x to 6.5x. Note the second column: our old stock FerretDB configuration is roughly at parity with MongoDB here, between 0.8x and 1.1x. The tuning is the story, not the engine.

Update p99 latency, workload A, milliseconds

Threads	MongoDB	FerretDB stock	FerretDB tuned default	FerretDB durability opt-in
16	156	202	100	19
64	664	1,447	388	94
256 (pool)	1,682	2,529	849	281

Footnotes, which travel with the numbers

"256 (pool)" is a client-thread count, not 256 connections. The YCSB MongoDB driver caps its pool at the default 100 unless mongodb.maxconnections is set, so 256 threads queue over roughly 100 connections on every column. The cap is symmetric and the comparisons stand, but true 256-connection concurrency was not exercised. Every arm saturates the 4 vCPU box by 64 threads anyway; nothing gains from 64 to 256.
MongoDB is IO-bound on this hardware profile. A 2 GiB ARC plus a 3.5 GiB WiredTiger cache against a roughly 10 GiB working set. Its flat ceiling near 750 reads per second is a real result for this box class rather than a harness artifact, and it would improve on larger presets with more memory. Read every MongoDB column as "MongoDB on a memory-starved 8 GB box", because that is what it is.
FerretDB stock ran PostgreSQL with max_connections=100, which is the stock configuration under test, so its 256-thread cells may also reflect connection limits.
Cross-box note. MongoDB and stock FerretDB ran on boxes built on 2026-08-18; the tuned default and the durability opt-in ran on the 2026-08-19 ablation boxes. Same flavor, same pinned image inputs, same corrected harness generation.
The durability opt-in is a write tool. It is about 0.9x the tuned default on pure reads, reproducible and unexplained, as noted above.

The same profile up and down the preset ladder

Everything above is one box. The obvious next question is what the tuned default does on the presets either side of it, so we ran the identical corrected harness and the identical tuned default profile on the other two dedicated flavors: the $35 preset and the $120 preset, hourly OVH boxes torn down when the runs finished.

One thing to get out of the way before the table. Both of these boxes ran FerretDB only. There is no MongoDB arm at 4 GB or at 16 GB, so none of the MongoDB multiples above travel up or down this ladder. This is FerretDB against itself on different hardware, nothing more.

Throughput at 64 client threads, ops/sec, tuned default profile with durability intact:

Preset	Flavor	Workload C, 100% read	Workload B, 95/5	Workload A, 50/50
Dedicated 4GB, $35	d2-4, 2 vCPU / 4 GB	2,141	1,995	1,208
Dedicated 8GB, $65	d2-8, 4 vCPU / 8 GB	4,065	3,919	1,752
Dedicated 16GB, $120	r3-16, 2 vCPU / 16 GB	5,274	4,857	2,177

64 threads is where every arm in the ablation saturated, which is why it is the one column worth putting side by side. The full 16, 64 and 256 thread grid stays with the raw results. Update p99 on workload A at the same thread count runs 407 ms on the 4 GB box, 388 ms on the 8 GB box and 283 ms on the 16 GB box.

This is not a clean memory ladder and I am not going to present it as one. The $65 preset is 4 vCPU. Both the $35 and the $120 presets are 2 vCPU. So the 16 GB box beating the 8 GB box, 1.3x on pure reads and 1.2x on the 50/50 mix on our hardware against the same 10 million record working set, is a RAM result achieved with half the cores, and it is the clearest evidence in this whole exercise that working set versus RAM is the variable that matters on this workload. The 4 GB box is short on both counts at once. The record count, the 2 GiB ARC cap and the 16K recordsize were held constant across all three; only shared_buffers scaled with the box, at 1 GB, 2 GB and 4 GB.

The 4 GB box ran genuinely memory-tight and the numbers say so plainly. After the 2 GiB ARC, 1 GB of shared_buffers and the YCSB JVM sharing the same machine, roughly 740 MB was free. Against a 10 GiB working set that is not a tight fit, it is no fit at all. It is the slowest row on every workload, and on the 50/50 mix it lands below the 8 GB box rather than somewhere proportional to price. Its read-mostly workload peaked at 16 threads, at 2,090 ops/sec, and got slower at 64, which is the shape of a box with no memory to spend on more concurrency rather than the shape of a box scaling. All three of its 50/50 cells hit the 600 second cap, so those figures are sustained ten-minute rates rather than completed one-million-op runs. Its load phase ingested at 1,425 ops/sec against 3,001 on the 16 GB box.

I would rather publish that row than leave it out. The honest reading is that the $35 preset is sized for a working set that fits in it, and the number above is what it does when you hand it one that does not. As with everything else here, these are dedicated tier figures on one profile of hardware, not a statement about Layerbase performance generally.

What that costs at MongoDB Atlas

We did not benchmark Atlas. I want to be completely clear about that before the table, because a price table next to a performance table invites a comparison I did not earn.

What I can compare is what you pay for the hardware. Atlas prices verified 2026-08-19 from mongodb.com/pricing, converted at 730 hours per month, compute only.

Plan	Rate	Monthly	vCPU / RAM / Storage
Atlas M10	$0.08/hr	about $58	2 / 2 GB / 10 GB
Atlas M20	$0.20/hr	about $146	2 / 4 GB / 20 GB
Atlas M30	$0.54/hr	about $394	2 / 8 GB / 40 GB
Layerbase Dedicated 4GB	flat	$35	2 / 4 GB / 25 GB
Layerbase Dedicated 8GB	flat	$65	4 / 8 GB / 50 GB
Layerbase Dedicated 16GB	flat	$120	2 / 16 GB / 100 GB

The Atlas monthly figures are compute alone. Storage, backup and egress bill on top of them. Our prices are flat and include the storage listed.

The honest version of the comparison is this: MongoDB, running on a box with equal or better specs than an M30, did 464 operations per second on the 50/50 workload. Tuned FerretDB on our $65 box did 1,752 on the same workload on the same hardware profile. Whether Atlas at $394 a month does better than our self-hosted MongoDB did is a question this benchmark does not answer, and I am not going to pretend otherwise.

What I am not claiming

This is one hardware profile. Everything above is bounded by it.

The box is deliberately memory-starved. A 10 GiB working set on 8 GB of RAM is where storage layout dominates, which is precisely why it exposed our recordsize problem. On a box where the working set fits in memory, the gap between these arms will be much smaller and the ranking may change.
At 1 billion records the write picture inverts. The third-party data I mentioned at the top has MongoDB winning writes at that scale, and nothing here contradicts it. Our numbers describe a 10 million record working set on a 4 vCPU box, not a billion records on a benchmark cluster.
The architectures are not equivalent. Atlas M-tiers are three-node replica sets. Our dedicated preset is a single node with backups and branching. That is a price-for-workload comparison, not an architecture-parity comparison, and if you need a replica set today then Atlas has something we do not.
We did not run Atlas. Said twice on purpose.
These numbers describe the dedicated tier. Different storage path, different neighbors, different everything. Do not read them as "Layerbase performance" in general.
Our own earlier comparison said MongoDB likely wins write-heavy workloads, and I am not retracting that so much as bounding it. It holds at scale and on hardware where MongoDB is not IO-bound. It did not hold on this box, against a properly configured PostgreSQL backend, which is a narrower claim than either of us probably wanted.

What changes for customers

The 16K recordsize and the tuned memory profile are becoming the default. They are rolling out behind a staged canary rather than all at once, because a storage property change on a fleet is exactly the kind of thing that deserves to go slowly, and because the ablation showed the memory half is capable of being negative when it lands without the recordsize half. Existing databases pick it up as they move through the rollout. Nobody has to ask for it and nobody pays extra for it.

The relaxed-durability profile is coming as an explicit opt-in toggle for write-heavy workloads, with the tradeoff stated in plain language at the point where you flip it. It is a real 4x to 5x on writes and it can lose the last instant of acknowledged writes on a hard crash. Both of those sentences will be on the same screen.

And the thing Atlas does not offer at any tier: branching. A branch of your database, on the same wire protocol, for a migration rehearsal or a CI run or an agent that you would rather not point at production. If you already have data in MongoDB, the Atlas migration page copies collections, documents and indexes into a managed FerretDB database and verifies the counts against your source, and the migration guide covers the compatibility checks worth running before you commit.

To be exact about what is on offer: MongoDB itself is not creatable in Layerbase Cloud for licensing reasons, so the hosted document story is FerretDB, which is Apache 2.0 licensed, speaks the MongoDB wire protocol, and is built on the DocumentDB extensions that Microsoft released under MIT and donated to the Linux Foundation. MongoDB does run locally through Layerbase Desktop and the Layerbase CLI, which is how the MongoDB arm of this benchmark existed in the first place.

The standing offer

The most useful thing this benchmark produced was not a table. It was the discovery that we had been shipping a storage default nobody had audited, found only because someone asked a question we could not answer from memory.

So the offer stands: if you are evaluating us and your workload shape is not represented above, tell me what it looks like and we will run it on our hardware at our cost and send you the numbers, including the ones that do not flatter us. That is roughly $5 and an afternoon, and based on this week it pays for itself.

You can start a FerretDB database at layerbase.com/create/ferretdb in the meantime.

Cloudflare D1 exports round every integer past 2^53

Bob Bass — Fri, 21 Aug 2026 14:16:00 +0000

The obvious way to get data out of Cloudflare D1 is wrangler d1 export. Cloudflare generates a SQL dump, you load it into SQLite, and you are done. It is the vendor's own tool, so it should be the highest-fidelity path out.

We tested it before shipping a D1 importer, and it is not. Any integer above 2^53 comes out of the dump as a different number, and then changes storage class on the way back in.

This originally ran on the Layerbase blog. Cloudflare does document the cause. It is one sentence on their import and export page: "Any numeric value in a column is affected by JavaScript's 52-bit precision for numbers." That sentence reads like a footnote about the JSON API. It is not. It is also about the file you were planning to migrate with.

Here is what it actually costs, measured end to end, and the rule we took away from it.

The measurement

Store the largest signed 64-bit integer, a plain 1.0, and nothing exotic:

CREATE TABLE t (id INTEGER PRIMARY KEY, big INTEGER, r REAL);
INSERT INTO t VALUES (1, 9223372036854775807, 1.0);

Read it back with a cast to text, so the value is not routed through a number on the way out:

SELECT CAST(big AS TEXT), typeof(big) FROM t;

9223372036854775807|integer

Exact, as expected. The database is fine. Now export and open the dump:

INSERT INTO "t" ("id","big","r") VALUES(1,9223372036854776000,1);

9223372036854775807 became 9223372036854776000. Off by 193.

Load that dump into SQLite and it gets worse, because the rounded literal no longer fits in a signed 64-bit integer:

sqlite> SELECT typeof(big), CAST(big AS TEXT) FROM t;
real|9.22337203685478e+18

The column is still declared INTEGER. The value in it is now a float. Nothing errored, the table is there, and the row count matches.

The REAL column has a quieter version of the same problem. 1.0 exports as bare 1. Because that column is declared REAL, SQLite's type affinity converts it back to 1.0 on import and you get away with it. In a column with no declared type, which SQLite allows and plenty of schemas use, the same 1 stays an integer and the storage class has silently changed under you.

Why a dump does this

A JavaScript number is a double. Doubles carry 53 bits of integer precision, so every integer up to 2^53 (9007199254740992) is exact and past that there are gaps. The dump generator formats each value as a JavaScript number on its way into the text of the file, which puts every one of your values through that funnel.

The database never held a wrong value. The renderer produced one.

Who this hits: snowflake ids, Discord and Twitter ids, nanosecond timestamps, bitfields, hashes kept as integers, and any 64-bit key handed to you by another system. All of them look like ordinary integers and all of them live above 2^53.

What makes it nasty is that nothing looks wrong afterwards. No error, no warning, row counts match on both sides, and SELECT * FROM users LIMIT 10 in a dashboard shows you numbers that look about right.

The inference that gets you

The reasoning that leads people here is sound and wrong: "the JSON query API returns numbers, and JSON numbers are doubles, so the API is lossy. Use the dump instead, it is a file of SQL text."

The dump is a file of SQL text generated by the same JavaScript. Text output does not mean the value avoided a double, it means the double got printed.

The useful version of the rule is not about which endpoint you pick. It is about where the value gets turned into text:

A value that crosses a JSON boundary as a number is suspect, whatever produced it.
A value that crosses as a string is fine, as long as the string was produced inside the database.

The other half: CAST is lossy on a REAL

Once you accept that, the fix looks obvious. Do not ask for numbers, ask for text: SELECT CAST(col AS TEXT). That is correct for integers, and it quietly loses data on floats.

sqlite> SELECT CAST(3.141592653589793 AS TEXT);
3.14159265358979

Fifteen significant digits, and the original had sixteen. That string does not parse back to the double you started with. Almost every migration tool that reaches for CAST as the safe option is making this trade without noticing, because the value still looks like a number and it is only wrong in the last place or two.

SQLite's printf has a format that does round-trip:

sqlite> SELECT printf('%!.20g', 3.141592653589793);
3.141592653589793116

Twenty significant digits is more than the seventeen a double needs, so it parses back bit for bit.

The encoding that survives

So the whole recipe, done inside SQLite before anything crosses a wire:

typeof(x) alongside every value, so the storage class is carried explicitly instead of inferred at the other end
integers as exact decimal text via CAST(x AS TEXT)
reals through printf('%!.20g', x)
text and blobs as hex(x)

Every value then arrives as ASCII text or NULL, and nothing numeric is ever handed to a JavaScript number.

Two edge cases we hit doing this for real, both worth knowing before you write your own:

Infinity has no JSON representation. It has to go back into the target as a SQL literal (9e999) rather than as a value the transport carries.
A TEXT column can hold bytes that are not valid UTF-8. SQLite lets you, and any layer that decodes the payload as UTF-8 will mangle them. They have to be bound as a blob and cast back to text on insert.

The principle underneath all of it: do type-preserving encoding inside the database engine, never in the transport layer. Do it in the engine and fidelity is a property of the SQL you wrote. Do it in the transport and fidelity depends on what JSON, a wire proxy, or a driver's type mapping happens to do that day, which is not something you can test once and rely on.

Checking data you already moved

If you migrated a D1 database with an export at some point, this is cheap to check. Against the source, per table with a suspect column:

SELECT count(*) FROM t
WHERE typeof(big) = 'integer' AND abs(big) > 9007199254740992;

Any non-zero count is rows that could not have survived the dump intact.

On the copy, the fingerprint is the storage class rather than the value:

SELECT typeof(big), count(*) FROM t GROUP BY 1;

real in a column the source reported as integer is the flip described above. Comparing the values themselves is harder than it looks, because reading them back through most clients puts them through a double a second time. Compare CAST(big AS TEXT) on both sides, not big.

What we ended up building

The Layerbase D1 importer never calls the export endpoint. It reads your rows over D1's query API with the encoding above applied inside SQLite, which is what makes an int64 id arrive exactly as stored rather than nearly as stored.

Routing around the dump turned out to fix two other things for free. Cloudflare's export blocks other requests to the database while it runs, so exporting a production D1 is downtime you have to schedule; reads do not block, so the copy runs while your Worker keeps serving. And export refuses outright on a database containing a virtual table, which quietly means "no full-text search", while a read-based copy recreates the FTS5 table and flags it for a rebuild.

The honest cost of reading a live database instead of dumping a frozen one: the copy is not a single point-in-time snapshot. We count rows before and after and report, per table, whether anything was written mid-copy. Migrate from a quiet database, or pause writes, if you need an exact instant.

If you are moving a D1 database, start at layerbase.com/migrate/cloudflare-d1. The step-by-step version, including what changes in your application code, is in Migrating from Cloudflare D1 to Layerbase.

The SSL modes 'prefer', 'require', and 'verify-ca' are treated as aliases for 'verify-full': what this warning means

Bob Bass — Thu, 20 Aug 2026 22:28:03 +0000

You deploy a Node app that talks to a hosted Postgres, and somewhere in the logs this shows up:

Warning: SECURITY WARNING: The SSL modes 'prefer', 'require', and 'verify-ca' are treated as aliases for 'verify-full'.
In the next major version (pg-connection-string v3.0.0 and pg v9.0.0), these modes will adopt standard libpq semantics, which have weaker security guarantees.
To prepare for this change:
- If you want the current behavior, explicitly use 'sslmode=verify-full'
- If you want libpq compatibility now, use 'uselibpqcompat=true&sslmode=require'

Nothing failed. Queries run fine. But "SECURITY WARNING" in capital letters is not something you scroll past comfortably, and on Vercel the line gets classified as error-level output, which makes it look worse than it is.

This originally ran on the Layerbase blog. The short version is below; the receipts for why providers still hand out sslmode=require are in a measured 8-client sslmode matrix.

The short version

Your app is not broken and your connection is not insecure. Today, node-postgres treats sslmode=require as full certificate verification, which is the strong behavior.
Nothing has changed yet. The warning is about a future major version of the pg package. As of this writing the latest release is pg 8.23.0, and the v9 it warns about has not shipped.
The fix is one word in your connection string: change sslmode=require to sslmode=verify-full. Same security you have today, warning gone, and your app keeps that security after the future change lands.

If that is all you needed, you can stop here. The rest of the post explains what the modes actually promise, why the maintainers are changing them, and the edge cases where the one-word fix is not the right one.

You did not upgrade pg. So why now?

The warning lives in pg-connection-string, the small library the pg driver uses to parse connection URLs. It was added in pull request #3473 and first shipped in pg-connection-string 2.10.0 in mid-January 2026.

Here is the part that confuses people: pg depends on that library with a version range, not a pinned version. So you do not need to upgrade pg to start seeing the warning. A fresh install, a lockfile refresh, or a teammate running an update can silently move the transitive dependency to 2.10.0 or later, and an app on pg 8.16.x that was quiet last month starts warning today. That is why a lot of people started seeing it around the same time without shipping any database changes.

The warning fires when the connection string is parsed, before any network connection is made, and only once per process. A pool of twenty connections logs it one time, not twenty.

What the SSL modes actually promise

sslmode comes from libpq, the official Postgres C client that psql and most non-JavaScript drivers are built on. In libpq, the modes are a ladder (official reference):

disable: no encryption.
prefer: encrypt if the server offers it, otherwise connect anyway. No verification of who you are talking to.
require: always encrypt, but do not check the server's certificate at all. The connection is private, but you have no proof it is private with the right party. Think of it as a sealed envelope handed to a stranger.
verify-ca: encrypt and check that the certificate was signed by a trusted authority, but do not check that the name on it matches the server you dialed. Any certificate from that authority passes, including one issued for someone else's server.
verify-full: encrypt, check the signer, and check the name. This is the only mode that fully protects you from someone impersonating your database server.

So in standard Postgres semantics, require is a much weaker promise than its name suggests.

What node-postgres does today, and what will change

node-postgres never followed the libpq ladder. Today, prefer, require, verify-ca, and verify-full all do the same thing: full certificate and hostname verification, using the certificate authorities your system already trusts. In other words, everything is silently upgraded to verify-full. That is the "treated as aliases" the warning is describing, and it is why the warning is not telling you that you are in danger. You currently have the strongest behavior no matter which of those modes you wrote.

The maintainers plan to align with libpq in the next major version, so that sslmode=require means what it means everywhere else. You can already see the shape of it: uselibpqcompat=true switches on the same parsing branch today. That is reasonable for consistency, but it has a sharp edge. Under libpq semantics, a connection string that says sslmode=require and nothing else drops from "verify everything" to "encrypt only, verify nothing", and one that also passes sslrootcert drops to verify-ca behavior: the certificate chain is checked against that authority, the hostname is not. Managed-provider strings almost never carry sslrootcert, so the first case is the one most apps will land in. Connections that used to be authenticated stop being authenticated, with no error and no visible change. That is exactly the kind of downgrade that deserves a loud warning years in advance, which is what this is.

The fix: sslmode=verify-full

If your Postgres host uses certificates signed by a public authority, which covers Neon, Supabase, Layerbase, and effectively every managed Postgres provider, the fix is to say explicitly what you are already getting.

Neon hands out connection strings in this shape (their docs):

postgresql://user:password@ep-xxx-pooler.us-east-2.aws.neon.tech/neondb?sslmode=require&channel_binding=require

Change one word:

postgresql://user:password@ep-xxx-pooler.us-east-2.aws.neon.tech/neondb?sslmode=verify-full&channel_binding=require

Leave channel_binding alone. node-postgres does support channel binding, but not through that URL parameter: you turn it on in code with the enableChannelBinding: true client option, which makes pg pick SCRAM-SHA-256-PLUS when the server offers it (shipped in pg 8.14.0). The parameter itself is only parsed and carried through by pg-connection-string; pg does not map or enforce it, and wiring it up to libpq's meaning is an open pull request. So it is a harmless passthrough for Node, and other clients that do act on it benefit from it.

Supabase connection strings do not include an sslmode parameter at all, so a Supabase project does not trigger this warning by default. If you are seeing it with Supabase, the parameter was added on your side, and the same one-word change applies.

Layerbase Cloud connection strings do say sslmode=require, so yes, our users on node-postgres see this warning too. If you are connecting from Node, swapping to sslmode=verify-full is safe and free: our server certificates are issued by a public authority, and Node verifies against the trust store it ships with.

We hand out require rather than verify-full because the same string has to work in every client, and stock psql fails on a bare verify-full. libpq looks for a local root certificate file that most machines do not have, and does not fall back to the operating system trust store the way Node does. We tested that matrix across eight clients (psql, node-postgres, psycopg, pgx, Prisma, drizzle, and the rest) and published the exact versions and error strings in sslmode across real Postgres clients.

One trap worth knowing: if sslmode appears in the URL, it takes precedence over an ssl object you pass to the pool programmatically. If you configure TLS in code, remove the parameter from the string entirely.

If you run your own Postgres with a self-signed certificate

The advice above assumes a publicly signed certificate. If you are pointing at your own box with a self-signed or private-authority certificate, note that node-postgres already fails on sslmode=require today (it verifies, remember, so an untrusted certificate is rejected with SELF_SIGNED_CERT_IN_CHAIN). You have two honest options:

Keep verification and tell Node about your authority: sslmode=verify-full&sslrootcert=/path/to/your-ca.crt.
Deliberately accept unverified TLS, for example inside a private network you control: uselibpqcompat=true&sslmode=require.

What uselibpqcompat=true actually does

The second suggestion in the warning text, uselibpqcompat=true&sslmode=require, opts you into the future libpq behavior right now. Under it, require means encrypt but do not verify the certificate, unless you also pass sslrootcert, in which case the chain is verified against that authority and only the hostname check is skipped. It silences the warning because you have explicitly accepted the weaker promise rather than getting it by surprise.

Only reach for it when that weaker promise is genuinely what you want, such as matching psql behavior against a self-signed server. And know that the parameter is a node-postgres invention: it is not part of the Postgres protocol, and non-JavaScript clients will reject a connection string that contains it. Do not put it in a string that anything other than Node will read.

Ways people try to silence it that do not work

node --no-deprecation does nothing here. Despite reading like one, this is a plain process warning, not a deprecation warning.
node --no-warnings (or the same flag in NODE_OPTIONS) does silence it, along with every other warning your process might ever emit. That is a sledgehammer, and you lose real signals.
There is no dedicated environment variable or option to turn off just this warning.

The connection string change is genuinely the answer. It is also the only response that does something useful: --no-warnings hides the message, while sslmode=verify-full makes your configuration say what it means, today and after v9.

I run Layerbase, a managed Postgres (and the rest of a multi-engine catalog) where every connection string we emit already has TLS on. We still ship sslmode=require on purpose, because of the client matrix above. If you want to see the string yourself, create a Postgres and copy it. Swap require for verify-full in Node and the warning goes away.

Becoming the person that I needed when I started

Bob Bass — Thu, 08 Jul 2021 20:49:47 +0000

The title is confusing so allow me to elaborate.

When I first started taking software development seriously, I didn't have a mentor. We could go into the psychology of why established developers aren't always friendly with beginners - but it doesn't seem necessary. It is a well-known punchline that Stack Overflow has discouraged more than a handful of beginners.

When I was just getting started I would often pay a random experienced developer I found on LinkedIn somewhere in the ballpark of $100 to talk through a problem I was stuck on. The call might last 15 minutes or 45 minutes but needless to say I exhausted all of my options before doing this.

Now that I am reasonably competent, it seems that I'm in a position to really make someone's day. I have found that if you tell a beginner that they are welcome to reach out to you if they get stuck, they almost always will. If you jump on a video call with a beginner, usually they are trying to accomplish something very simple. You may have spared 15 minutes out of your day to help a perfect stranger, but that 15 minutes may have prevented them from wasting a month moving in the wrong direction.

I can provide a list of anecdotal information but instead I would like to encourage the more experienced developers to think back to a time when you were stuck on something very simple just because you were missing a small piece of context. Maybe you took a course and the instructor took something for granted that you really needed explained.

I have found that the small investment of time that I put into helping the occasional stranger seems to have a disproportionately positive effect on them. No matter where I value my time, 15 minutes of it is an order of magnitude more valuable to a newbie developer than most other people.

Of course there's a caveat to that. Time is your most valuable asset and you should never write that off. I also believe that what I'm proposing isn't completely selfless.

When I help a beginner, I like to think that it's an opportunity for me to reinforce my knowledge, network, and make someone's day all at once. It feels good.

I would like to encourage anyone who stumbles across this post to think back to a time when you've wasted days, weeks, or even months working on solving the wrong problem. Think back to the last time something clicked for you in a really meaningful way that caused you to start over instead of refactoring.

I remember what I needed when I got started. I needed an experienced developer that was willing to spend 15 minutes talking through a problem with me. I needed someone with a real world perspective to gently nudge me back on track. I needed to feel like I wasn't massively inconveniencing every developer that I spoke with, simply because I was lacking some insight.

I've been making an active effort to be that mentor to other people. It's not surprising that people are incredibly grateful when you spend a few minutes helping them out, the part that is however surprising - is that I think I've experienced more growth since I've opened myself up to do this.

I hope to see the culture shift to be less critical towards the beginners who are often already uncomfortable asking for help.

Project NextApp (beta) needs some testers

Bob Bass — Mon, 14 Dec 2020 11:52:21 +0000

I built a platform that I think can be very useful for people to learn new technologies. To be honest, I built it for myself because I couldn't find it anywhere else.

I have a theory that the best way to learn new technologies is by building a small project with it with no real expectations. It also helps when there's a community to consult with.

2 years ago, I never thought I would be a professional developer. I started dabbling with software for my business and realized that I enjoyed it much more than I enjoyed owning a call center. I started building small projects and it was a very effective learning tool that greatly exceeded anything that tutorials did for me.

I joined a startup accelerator to try to make a career out of my software. Now I'm at a crossroads where my software that I've been building long-term is getting really boring but I have a long waiting list and I can't abandon it. To prevent burnout, I've been looking for small weekly hackathons. Since I've been unable to find this. I created it.

ProjectNext.app is a community built around learning new technologies with small projects. Let's say that I want to learn to publish an NPM package. maybe I want to set myself a goal of one week to publish an NPM package that initializes TypeScript inside of a legacy Vue.js app. I can set that as a vague goal and set it to 1 week.
Over the course of that week, it might turn out that instead - I want to build an NPM package with a small standard library of functions that I always seem to be writing. I might modify the project to be a two-week project and update the goal.
The Monday following the project completion date will have a community zoom call hosted where I get to present what I built, what I learned, and what I plan on doing next. Other people from the community can share their thoughts with me and maybe point me in the right direction if they see that I'm stuck on a concept. Maybe, during the call I share that my next project is going to be a GoLang REST API, and user123, also on the zoom call happens to be a go enthusiast. They might want to comment on a really good udemy class that they took and recommend.

Meanwhile, you're building up a profile that will track which technologies you learn over time. It's possible that in the future I can use this platform to generate resumes. I would like for this platform to be incredibly friendly to beginners but also I wanted to be a rewarding experience for all of us developers who are constantly building side projects and learning new technologies.

Learning new technologies is 50% of the "mission" while the other 50% is helping developers find a spark for a long-term idea by providing a framework to iterate quickly and get feedback until they find something more permanent.

It integrates with GitHub so there's a lot of room for a lot of cool features down the line.

ProjectNext.app was its own first submission. It was a proof of concept. I wanted to see if I could build it in one week and learn some new technologies in the process. I did. I also went through a life-changing career change at 30 years old and I want to help other developers do the same. I'm very interested in mentoring some beginners and I think that this platform can help me scout out some beginner developers who might need that added little bit of direction.

The concept is very early on right now. I have a slack channel that is going to act as a hub for casual conversation until I build a community right into the website.
I have a handful of other developers who are also in the same accelerator as myself who are also willing to help beginners, while simultaneously interested in using this platform to hone their own skills.

A few features are missing right now. It doesn't yet have the ability to post and update. That functionality will be finished later this week. The same is true of following projects and creating teams.

I have had at least two companies express interest in sponsoring prizes for small hackathons. It's something I'm definitely going to explore a bit deeper.

I will share a proper release on here once all of the features are finished being implemented, but I would really love a few people to join early if only to help me replace some of the placeholder projects with real ones.

If you are a beginner and you're interested in this, I'm also happy to provide a little bit of mentorship to help you get going if you choose to join. I'm looking for a community feedback to help me figure out a direction to take this thing. It's not aimed at becoming a viable business model, I'm just creating a platform that I personally wish existed and have been unable to find so far.

Please let me know your thoughts. Does this sound interesting? Are you interested in being an early tester? What turns you off from this idea? What excites you about it? This whole thing is very new. I also recorded the process of building the app from start to finish and I'm going to host that video so that it's embedded on the project page. If it goes over well, I'm going to make that a permanent feature so that others can do the same thing.

I'm looking forward to getting some feedback and helping some developers of all skill levels to level up their skills.

Does ProjectNext.app have a place in the 2021 developer ecosystem? You tell me!

Leaving stability to bootstrap a SaaS startup

Bob Bass — Fri, 04 Sep 2020 08:30:30 +0000

I have been with some people may have referred to as a bottom feeder in the past. Almost 10 years ago I opened a debt collection agency and it has been fairly stable and moderately successful but I sold it in November of 2019 so that I could pursue automation full-time.

I won't bore you with the details of how I ended up starting a small business automation agency but pivoting entirely to bootstrapping a startup aimed at creating cutting-edge software for the debt collection industry, but I will mention that over the years I created software for my agency using C# and .NET. Did that collection industry is notoriously 20 years behind the rest of the world when it comes to technology and I understand why that is.

Nobody likes to be involved with the debt collection industry. There are bad actors who give the industry a bad name, consumer lawsuits are rampant, laws are unclear, outdated, and ambiguous, but most importantly - nobody has seen the need to fix a system that many people won't acknowledge is broken.

If you are using dev.to, it's probably fair to assume that you are technologically inclined. That isn't the case for people in the debt collection world. Some agencies are processing $1 million monthly while using physical desk phones and Windows XP desktop. That isn't an exaggeration, it's not even an edge case.

There has been one platform that tried to create a serverless debt collection platform (as opposed to the current standard of having a physical server in your office), and this company clearly didn't have experience collecting delinquent accounts. The software is verbose and complicated. it's very hard to be productive when the people who design the software don't really understand the industry. I've also noticed that the debt collection industry is very resistant to change and when I release my app, I have my doubts about whether or not people are going to give it a shot even though I will feel confident making the claim that their revenue should increase significantly if they are using a well-organized, reliable, and streamlined platform design specifically for their day-to-day operations. I am building the software that I had always wished existed when I ran my agency.

When I started this project, I intended to build it using asp.net and my JavaScript skills were limited because I had spent most of my time and energy learning C#. I believe it was fortunate that my brother who was living in Silicon Valley at the time pushed me to dive into single-page applications with JavaScript. I brushed up on my JavaScript and learned to React pretty quickly but I didn't fall in love with it. I then built a small app with VueJS after watching The Honeypot.io documentary about Vue. It's fair to say that the MVC-like structure clicked with me in a way that I could only describe as 'common sense web design'.

At the time I'm writing this, I have put in over 2,000 hours coding this platform. I have hired a part-time developer in Nigeria who is incredibly hard-working and skilled considering he's fresh out of a boot camp, and I have even relied on him to teach me best practices for team-based version control which I never had to learn since I've always built solo projects.

At this point I've joined a startup accelerator and I really enjoy it. It helps keep me motivated and it keeps me hopeful about doors that it may open for me. All of this isn't without its downsides.

The money that I made selling my agency has been almost completely exhausted covering development expenses such as server hosting and developer commissions. I'm technically unemployed since I choose to focus on this startup which is not yet making money and I'm putting a lot of faith into the idea that I know this industry very intimately and that my platform will be groundbreaking enough that people will be interested in trying it out.

So - for better or worse, I've decided to sell my house to provide me with additional runway. The papers are signed and the sale will go through any day now so there's no turning back. I'm passionate about this and I believe in myself.

The worst case scenario is that the app crashes and burns which I don't think is incredibly likely but if that happens, at least I will have gained invaluable experience building out an entire CRM and automation platform from scratch. I've learned Node, Vue, Firebase/Firestore/Cloud Functions, MySQL architecture, custom API integration, and version control in a team setting.

Hypothetically, if this startup fails - I'm not leaving empty-handed. I've learned a valuable lesson about how passionate I am when it comes to software development and I would feel confident joining a remote team working with a similar stack. I've also proven to myself that I can learn and implement new skills quickly and efficiently. I'm much more competent than I was when I started down this path and I even find myself refactoring old code to prevent technical debt further ahead into the future.

There's a lot of uncertainty right now, much of it stems back to my inexperience with marketing and sales, but I'm determined to push on and I will be sure to update here once there are some meaningful developments. I would be lying if I said that I wasn't terrified, or if I didn't admit that I feel like I'm making reckless decisions.

Today is my 30th birthday and I don't have the stability that I've gotten so used to over the past decade because I'm risking quite a bit to pursue a dream which has long been on the back burner.

I hope that someone who may be interested in doing the same can possibly gain some perspective from my experience so far, likewise - I would be thrilled to get some feedback from anybody who's been through a major career pivot from something stable to something uncertain for the sake of passion.

As I've done for quite a long time now, I will continue to share my experiences as I go down this reckless path of entrepreneurship.