Rentivio connects home owners in Greece with professional short-term rental managers. Owners list homes that sit empty, managers lease them for a fixed monthly rent and run them for guests.
A listings platform comes down to two kinds of data: records that keep changing shape, and lots of photos. Here's how two open-source tools handle them for us, and why we'd pick them again.
CouchDB: listings that can grow without migrations
A property listing never stays the same for long. We started with location, rent and photos, then added minimum lease duration, amenities, deal status, moderation flags and more. In a relational database, every one of those changes is a migration. In CouchDB, a listing is a JSON document, so a new field is simply a new field.
What worked well for us:
- One database per concern. Listings, users, payments and chat each live in their own CouchDB database. Each has its own indexes and its own backups, and a heavy query on one doesn't slow down the others.
-
Revisions catch conflicting edits. Every update has to send the document's current
_rev. If two people edit the same listing at once, the second save fails instead of silently overwriting the first. We got that safety for free. -
The app sets up its own database. On startup, our Node.js service creates any missing databases, design documents and indexes. A fresh environment is ready with a single
docker compose up, and a new index ships in the same commit as the query that needs it. - Mango queries feel familiar. Searching by area, price or status is a JSON selector plus an index. If you know MongoDB, you already know most of it.
RustFS: photos that never touch our server
Listings live or die by their photos, and image traffic is the fastest way to overload a small API. We store photos in RustFS, a lightweight, self-hosted, S3-compatible object store.
The key decision: image bytes never pass through our API. When someone uploads or views a photo, the API checks that they're allowed to, then returns a short-lived presigned URL. The browser talks to RustFS directly.
The result:
- Our API only sends small JSON responses, so it stays fast even when someone scrolls through dozens of photos.
- Because RustFS speaks the S3 API, we use the standard AWS SDK. Moving to any other S3-compatible provider later is a configuration change, not a rewrite.
- It runs as one more container next to the rest of the stack, with its data on a named Docker volume. Development and production behave the same way.
- Like CouchDB, the bucket is created automatically on startup, so there's nothing to click through in a console.
What we learned
- Pick storage by the shape of the data. Documents that change go in a document database. Large binary files go in object storage, not in the database and not through the API.
- Let the app set up its own infrastructure. Self-creating databases, indexes and buckets removed a whole class of "works on my machine" problems.
- Self-hosted doesn't have to mean complicated. CouchDB and RustFS are each a single container with a persistent volume, and both have been low-maintenance for us.
If you're building a small marketplace and wondering whether you need a managed cloud database and storage from day one: you might not. CouchDB and RustFS have carried Rentivio comfortably so far.
Curious about the product? Have a look at rentivio.gr. Questions about the setup are welcome in the comments.
https://rentivio.gr/?utm_source=devto&utm_medium=social&utm_campaign=cm-post-6
Top comments (0)