Usually, when I start on a new venture, big or small, my tech stack is almost always the same. I often explore slightly new technologies and frameworks along the way. But I never stray far away from Vanilla JS, PHP (please don’t judge me), Postgres for the database and Heroku for hosting. Using these allows me to get up and running quickly, which enables me, in theory, to build quick and fail fast - following the mantra of all good Indie Hackers.
This approach was no different when I started thinking about the SprintDock website (a working title) and backend infrastructure needed for the first time back in April 2021, when I was still working full-time. This was until I started playing around with Stripe JS.
I had used Stripe in the past with another project, but it had been a good few years since then. I was well into the development of SprintDock, of building a functional MVP, when they [Stripe] announced Stripe Elements, which I may go into more detail about in another post. But until then, you can find out more here.
With the introduction of Stripe Elements, it was the perfect time to dive deeper into the Stripe ecosystem. So I opted-in to the also newly available beta for Stripe Search API. This incredible endpoint allows for SQL-like querying across all Stripe objects, revealing the ability to search for a Stripe customer now by email address. This was a game-changer for me, but let me rewind a little...
I am the founder of SprintDock, a MacOS based tool for productivity. SprintDock uses existing 3rd party infrastructure and API's only. It was not designed to replace existing productivity systems like Notion, Atlassian or Google Calendar, to name just a few integrations. Instead, it was designed to 'Supercharge Existing Workflows'. So there isn't much that requires a centralized database other than user data and other metadata.
With this, I experimented with replacing the existing query to store user data within my Postgres database and instead, just create a customer object at the start of the user signup journey. This allowed me to easily store the name and email address, along with additional metadata such as the User ID/Organization ID, from the respective 3rd party service amongst a few other minor reference only data points. The only thing other than user data I was storing within a Postgres DB, was storing encrypted license key information, something unfortunately Stripe does not have a tool for. To go slightly off-topic, this is why Paddle (5% + $0.50 per transaction) is winning people like myself (people building desktop apps) over as all of that is taken care of, and to my knowledge, they are the only company doing License Management. Selfishly, as I do not like Paddle, I hope Stripe considers looking into adding support for Licence Management.
All of this experimentation was just to see if this was possible, not if it was scalable. But as time went on, and I started speaking to advocates and employees from Stripe to hear their thoughts, it turns out I was not the only one who had been able to build almost entirely within the Stripe Eco-system, and it started to make more and more sense, for the following reasons…
Stripe processes transactions from 3.1 million websites across 46 counties, They store incredibly sensitive payment information which legally requires frequent audits of their systems for security vulnerabilities. Stripe has never publicly acknowledged any breach since its inception and it has the trust of major enterprises globally.
Regardless of the use protocols such as OAuth and SHA-256 encryption (which I was using), Stripe offered significantly better security right out the box.
There are many great tools that allow you to build out, manage and maintain databases infrastructure, starting from the CLI right up to tools like TablePlus (Highly recommended). But Stripe’s Dashboard presents all datapoints upfront and centre, which can be accessible, and almost fully mutable from any device, even on the go with the Stripe iOS app and can be easily shared across teams without having to create special permissions.
Stripe is known for its highly scalable, well optimised APIs. However, up until October 2021, querying a customer by email address, or querying metadata was not possible with an API request unless you wanted to query several endpoints all at once, which just isn’t scalable. But with the launch of the Beta Stripe Search API, this became a whole lot easier. This is not perfect, you can only do complex SQL-like queries with select objects. It should be noted this does not include metadata. However, the API is still in beta and from my understanding, this functionality is coming in the next few months.
I’m sure many of you are aware, storage and databases can be costly. AWS Aurora (Postgres & MySQL) charges $0.10 per GB of storage. Heroku gives you a free ‘Hobby Dev’ Postgres Database, but this is limited to 1000 rows. This does in fact work for me. But for scalability, this can become costly very quickly as is the same with AWS. Stripe on the other hand is free. You only pay 2.9% + $0.30 on any transaction.*
But it’s not without its limitations of course. Stripe is not a Database, nor is it a storage solution. You can not store complex objects such as JSON and you can not JOIN tables and perform other such advanced queries as you can with Postgres, MySQL or any non-SQL databases.
Furthermore, data storage within Stripe is limited. As of writing this, you can only store up to 500 characters within a field and you can only create 50 metadata objects per parent object. More information here. This is the reason that I still use Postgres for License Keys, as a metadata object cannot hold the data used to validate each device.
Am I suggesting that if you use Stripe, or even if you don’t, to migrate your existing databases over to Stripe? Absolutely not. In most cases, this just isn’t feasible for the reasons discussed. But if you do not require a complex backend and database infrastructure, like me, it’s certainly worth considering, at least to begin with.
My name is Joe Barbour. I am the solo-founder of SprintDock and am #BuildingInPublic on Twitter so drop me a follow and DM me or comment below if you have any questions or hot takes. And for full transparency, I am not associated with Stripe in any way and this post is not sponsored. I am just a fan.
Pre-face: I like this kind of post and as a curious cat that I am I checked out your product: I gotta say it's hard to read the text on your site, after 10 seconds I had to squint to figure out what was going on.
With regards to the actual topic discussed I totally agree with you - Stripe shouldn't be used as a database for anything but minor metadata not information on which you will perform routine operations (joins, unions etc)