Why I Love PouchDB
This is an essay born of mixed feelings. I got into CouchDB's ecosystem because my first big job where I somehow excelled, was as a developer advocate for Cloudant. That job went sour in a bad way, but I have still orbited its ecosystem because the ethos of CouchDB as a tool remains compelling in an era that calls for transformation. Tools shape options; the toolmaker produces choice, and must be held accountable to such. Artisanship necessitates consideration. Like the form of a sonnet, ethics demand and inspire cleverness. I write this essay because we need better tools than we have. The best tools we do have are either insufficient or captured or, realistically, both. PouchDB, to me, is the best option out there for solving a problem at the heart of what makes the internet suck at every level, and I hate that because it is not good enough. So here's why I love it.
PouchDB is a JavaScript database based on CouchDB. It has a subsystem of storage adapters that allow it to transparently run in different environments, like a server or browser. It supports reads and writes, batch operations, and supplies a map/reduce query system where queries always act on predefined indices, so they run in constant time. Nice! When it runs in the browser, it stores your data on your device (usually in IndexedDB) which is key to separating development from the management of infrastructure.
Replication is CouchDB's killer feature, and PouchDB does it too. When properly set up, a CouchDB server can replicate a database to a browser running PouchDB, syncing their state in a reliable, durable way. I use PouchDB for local-oriented development, but even in a server-client situation the advantages of clients querying local copies of authoritative records are significant. Not only does the client app remain functional during degraded connectivity, it can do its own computation over that data, maintaining and even customizing indices that the server need not build.
As a toolmaker, I hate running infrastructure. I make the calendar wheel, you make the watch. I have to design with the idea of the watch in mind, its possibility. Indeed I can rely on its eventuality: the tool can only be used in such, pending stranger cleverness. So apps that need databases are tough for me to write, because who runs the database? If I run the database for a service, I'm running a SaaS operation and it will become my job. If the user runs the database, well, given most database requirements, that's a lot to ask of people who have never opened a terminal — except for PouchDB.
If the user runs their own database, then all their data belongs to them in an obvious way. It's on their computer, so their privacy and autonomy are provided by default (to the best ability of the host machine to escape infiltration, user error, etc). I as a developer need know nothing about the user's system, only that it is running my software.
In order to make my software available to the most people, I try to publish to widely supported platforms. The uniplatform of today remains the web browser, with mobile apps for Apple and Android the runner-up. Mobile development is its own bizarre world, fractured linguistically and festooned with the meaningless distinctions of propertarians and profiteers. When omniplatforms like React Native work their magic to deploy to the web and mobile at once, they are transpiling from JavaScript. The dream of the JVM lives in the land of JS. Such breadth of influence deserves wise administration, no? However, governing browser environments as a system of standards has proven a thorny process.
Because we are wage slaves, we must work to survive. Ideally one works to support ourselves, our families, and our communities, through the direct fruits of our efforts. Instead, well, you know the saying about dimes and times. This means the vast majority of our energy is devoted to some bizarre task, and not whatever we really care about. (People become poor artists because being paid-off servants of this barbaric society is excruciating. I need us to become servants of a true civilization, a mutual covenant beyond greed and war. I need you to find it in your heart to believe, because how will it happen without faith that it could?) When it comes to tech standards, the utility of tech to capital means there are always stooges paid to sit on standards committees. They may see themselves individually as judicious or conscientious, but we are produced by circumstances and animated by greater forces than mortal will alone. You are paid to sit there because it is first and foremost profitable. Are you really such a clever threat that the appearance of your profitability undermines its rationales? Because, I need you to be.
Besides the committees' paid inhabitants, volunteers may also find their way to influence, but unless they are blue-blooded, they do this at the expense of their wages and rest. This leads to burnout, sapping already small ranks. Thus the greater proportion of the consensus of key standards bodies will belong to the will of colonial corporatists, as a result of systemic pressures. The specifics of any instance will only trend around this pattern.
The browser's role as a uniplatform is not a desirable condition either. By all means, the JVM should be the uniplatform, and even that was conjured by corpers; its failures owe to their foolishness. The browser's primacy is a historical accident representative of the incompetence of late capitalism's corporatist character. The body without organs sold them all off; the firesale runs down to ashes. A federation of civil servants recognizing the task of computerization as one of infrastructural development and public need, would not arrive at the choices we have made.
So anyway, PouchDB runs in the browser. That means I can use it in apps that people run by clicking a link. My app's database runs in their browser on their machine, which allows me to code as though I have a database full of user-specific information without having users at all. That's why I made the diary Spellbook, to demonstrate how this pattern centers the user's autonomy without violating their privacy. Also because I needed a diary with tags and text search.
Regarding replication, practically, you can only sync with CouchDB servers, and anyone worth their salt has that shit behind a reverse proxy, a load balancer, cluster instrumentation — you wanna ask users to run that? Furthermore, replication in CouchDB assumes trust: you pull updates of all kinds, mutating the underlying data with presumed consent. Creating multi-user databases guarantees a future of document conflicts that look like data loss unless you understand CouchDB's data model. Once you understand CouchDB's data model, you'll know better than to try. The trust that the replication model asks for is designed for peers in a cluster, not individuals and their social networks.
And yet, that's the big problem we're all trying to solve, isn't it? Besides the obliteration of capital and colony, the unprecedented opportunity of mass computerization is the design and production of comms networks for freeform socialization, including commerce and community-building, which are limited only by the speed of light and our ability to lay cable. Social media is more often than not a form of self harm, yet the good it has allowed is undeniable. As a queer person, where queerness is a characteristic not bounded by time or space but only the existence of life itself, comms that trivialize distance and permit arbitrary mediums are transformative to the organization of material power for us as a nation, as a people. That good exists alongside the cultivation of multiple genocides, so clearly something isn't working right. But I see the glimmer of hope in your beleaguered eyes. Do you believe as I believe that we could have better? Somewhere deep inside of you, I suspect that belief smolders unquenchable. We can do this right. We can do the craft justice. We can live up to the duty bequeathed by conscious choice, the obligation of stewardship.
PouchDB is the best game in town for living up to that as an artisan, and it isn't good enough, not by a long way. I won't even talk about the map/reduce system because evaling user-supplied Spidermonkey JavaScript to build indices is such a footgun you could lose your leg. Grow up and learn Datalog (and map/reduce in Datalog), or cunt up and implement SQL. NoSQL is a scam and an excuse, a name that shames the genuine innovations under its banner. We do not have the mandate of heaven; we have not earned it.
So I love PouchDB. I use it. I build with it. I laugh at Supabase and host my e-vomit on GitHub Pages for fucking free. Try it out. Maybe you'll make something you love.
Maybe it will inspire you to demand better.