We couldn't stomach the session replay bill, so we built Filmroom
Update, September 2026. Filmroom is its own product now. It lives at filmroom.dev, with its own hosting and its own billing, and that is where you sign up for it. It is no longer something you deploy from a Layerbase account. The story below is how it got built and what it does, and all of that still holds; only the place you buy it changed.
Short version: Filmroom is our own session replay tool, built because self-hosting PostHog cost us hours and never produced a setup we trusted, and the FullStory quote opened around $30,000 a year. It records the DOM rather than video, masks anything you mark with a single attribute, and pins console errors and unhandled rejections to the exact moment in the exact session that hit them. It stores everything in Postgres.
We had a marketing problem, and it took us a while to admit it was a marketing problem and not a "our users are wrong" problem.
We kept shipping features nobody found. We would write a page explaining something we were genuinely proud of, and the metrics said people scrolled past the whole thing. Those long, careful blocks of technical text we spent afternoons on? Skimmed, if that. We could see people arriving and leaving, but not why they left or what happened in between. Which parts of a page got read. Which got ignored. What caught the eye and what was invisible.
Analytics tell you what happened. They do not tell you why. We needed to watch how visitors actually moved through the front end.
Self-hosting PostHog, and the $30k FullStory quote
There are real products for this. PostHog and FullStory both do session replay well, and we are not pretending otherwise.
The catch is what we do for a living. People hand us their databases. That means we are careful, sometimes annoyingly so, about what runs on our pages and where anything gets sent. Whatever we used had to be front-end only and had to keep sensitive values out of the recording entirely. That ruled a lot of things out fast.
So we tried to self-host PostHog. We lost hours to it. Not "one frustrating afternoon" hours, more than that, and we came out the other side without a working setup we trusted. Then we got a quote from FullStory. The starting number was around $30,000 a year. For a tool to watch our own marketing pages. We closed the tab.
At that point building it ourselves stopped sounding crazy.
Two birds
So we built an internal tool. It was also our first real attempt at something bigger: a way to run a full application as a thin layer over a managed database, which is what eventually became the Embedded Layerbase Apps platform.
It worked. We got the insight we were after, and we got the app-hosting groundwork at the same time. The session replay tool we needed to debug our own site turned out to be the proof that we could host first-party apps at all. That tool became Filmroom, and it eventually outgrew being a side project bolted onto a database company.
What it actually does
The recorder is not video. It captures the DOM with an rrweb-style approach: a serialized snapshot plus a timestamped stream of changes and input events. Playback rebuilds the real page and replays it on a virtual clock. That means recordings stay crisp at any zoom, you can search them, and the storage footprint is tiny compared to a screen capture.
Privacy masking is built in, and it is the first thing we set up. Mark an element and everything inside it is masked with a single attribute. Secrets, connection values, anything you do not want stored never leaves the page in the clear. Inputs are masked by default. You decide what stays visible, and the safe default is that sensitive things do not.
To be clear about what this is for: it shows you how people interact with your front end, which parts of a page work, and where a flow falls apart. It is a debugging and design tool. You are looking at pages, not people.
It also catches front-end bugs and pins them to the replay. Console errors, thrown exceptions, and unhandled rejections get captured as they happen and marked on the session timeline, so a bug arrives already attached to the exact moment and the exact session that hit it. The errors view groups them into issues rather than occurrences. A bug that hit four hundred visitors is a single row that says so, not four hundred near-identical rows. Each issue shows how often it fired, how many visitors and sessions it reached, and when it was first and last seen, and expands to the individual hits. Watch latest opens the most recent one that still has a replay, because errors outlive their recordings. No more guessing which session the error report came from.
There is a proper dashboard around it too: search, sorting, and filters that persist in the URL, so a view worth sharing is just a link you can send to a teammate.
The version we ran on Layerbase was single-tenant: one customer, one database, no sharing. Hosted Filmroom works differently now that it is its own product. Every workspace is isolated at the row level, with database constraints doing the enforcing rather than a convention someone has to remember, on a shared engine. If you want a database that is entirely yours, that is what self-hosting is for.
Setup is a script tag
The install story is one line. You drop a script tag on the page and you are done.
<script
src="https://api.filmroom.dev/v1/your-site.js"
data-site-id="marketing"
data-write-key="wk_live_..."
data-ingest="https://api.filmroom.dev"
async
></script>That is the shape of it. The exact snippet, with your own site id and write key, comes from the Filmroom dashboard: grab it, paste it in, and sessions start showing up. If you get stuck, we will help you wire it in. It is not a project.
What it costs
Filmroom sells itself now, at filmroom.dev. Current pricing is on that page, and it is the only place it is quoted, so nothing here goes stale behind it.
What has not changed is the shape of the pricing. It is a flat number, not a per-session meter, which was the whole reason we stopped paying for one. If you came here hunting for a FullStory or PostHog alternative whose price is a number instead of a quote, that is still the pitch.
The Layerbase side of this is simpler than it used to be: you do not need a Layerbase account, a Layerbase database, or a Pro plan to use Filmroom. It brings its own storage. If all you want is session replay, go straight to filmroom.dev.
FAQ
Is Filmroom a video recording of my visitors?
No. The recorder captures the DOM: a serialized snapshot plus a timestamped stream of changes and input events. Playback rebuilds the real page on a virtual clock, which is why recordings stay crisp at any zoom, stay searchable, and take a fraction of the storage a screen capture would.
How do I keep sensitive values out of a recording?
Mark the element. One attribute masks it and everything inside it, so a wrapper covers a whole panel of connection details in one go. Inputs are masked by default. The safe direction is the default: you opt things into visibility, not out of it.
Where do the recorded sessions live?
In Postgres, and hosted Filmroom runs that for you. Your workspace is isolated at the row level, enforced by database constraints rather than by application code remembering to filter. If you would rather the database be entirely yours, Filmroom can be self-hosted.
Does it catch JavaScript errors?
Yes, and it pins them to the replay. Console errors, thrown exceptions, and unhandled rejections get captured as they happen and marked on the session timeline. The errors view groups them into issues rather than occurrences, so a bug that hit four hundred visitors is one row saying so, with first-seen and last-seen and a Watch latest button that opens the most recent hit that still has a replay.
How long does installing it take?
One script tag, copied from the dashboard. Sessions start showing up as soon as the page with it deploys.
Do I have to use Layerbase to use Filmroom?
No, and you never really did. Filmroom is a standalone product at filmroom.dev with its own account, its own hosting, and its own billing. It has no dependency on a Layerbase account or a Layerbase database.
Where this goes
Filmroom left home. It is a standalone product at filmroom.dev now, which is a better outcome than being app number one in a catalog that a database company maintains on the side. Layerbase went back to doing the thing it is good at, which is running databases.
We are not selling hosted app containers to new customers any more, for the same reason. If you have a tool you would genuinely like to run on the architecture underneath this, email ops@layerbase.com and we will talk about it, but it is a conversation, not a signup form.
If you want to see how visitors actually use your front end, without a per-session meter and without a $30k starting price, try Filmroom. We built it because we needed it. It turns out we were not the only ones.
Keep reading
- Layerbase vs Tinybird: real-time analytics without the usage meterTinybird turns ClickHouse into a managed real-time analytics API with usage-based billing. Layerbase gives you the same ClickHouse engine on a flat monthly price and leaves the API layer to you. Here is the tradeoff, and when each one wins.
- A database setup for software development agenciesIf you build software for clients, you do not have a stack. You have everyone else's. Here is how to run all of those databases, local and hosted, from one place.
- MariaDB 13.0 and 12.3 LTS on Layerbase: which line to pickMariaDB 13.0 and 12.3 are now offered on Layerbase alongside 10.11, 11.4 and 11.8, and the older lines have been refreshed to their current patches. Here is what actually shipped in 13.0, what 12.3 changed, why one of them is the LTS and the other is not, and what happens to databases already on 11.8 (nothing).
- We put the Postgres write-ahead log on object storage. We did not put the database there.Databricks rebuilt Postgres so that object storage is the database. We shipped a much smaller thing: the write-ahead log leaves the box continuously, the live database stays on local disk. Here is the whole design, the two bugs that taught us the most, and an honest account of what this architecture does not buy.