Choosing a backend platform, including when not to
What actually decides it, where Backenly lands on each criterion, and the cases where you should stay on what you have.
Why teams start looking
Worth being precise about the trigger, because two of these five are not problems a different platform solves.
The data model stopped fitting
Usually this arrives as a query the product now needs and the database cannot express without restructuring. It is the most expensive reason to move and the one that gives the least warning, because nothing is broken until the requirement appears.
Nobody wants to own the operational half
The platform works; the schema migrations, policy reviews, and incident response around it are the part that keeps slipping. This is less a complaint about the tool than about who has time, and it is the reason most likely to lead somewhere useful.
The bill became unpredictable
Metered pricing tracks usage faithfully, which is a virtue until a chatty access pattern turns into a number nobody forecast. Note that the fix is often a data-modelling change rather than a new platform.
An agent is now writing most of the code
A workflow built around a coding agent asks different questions of a backend: what the agent can read, what it can change, and what happens on a bad turn. A platform chosen before that shift was not chosen against those criteria.
The exit path was never checked
Sometimes the trigger is simply realising nobody knows what leaving would involve. That is worth resolving on your current platform first: if the answer is a database dump, you may not need to move at all.
What actually decides it
Six questions, roughly in the order they tend to bind. Ask them of any platform you are considering, this one included. Each carries where Backenly lands, stated plainly enough to check.
What is the data model, and does it match how your entities relate?
This is the decision that is hardest to reverse. A document store is excellent for simple, self-contained records and demanding once records reference each other, because the work of keeping denormalised copies consistent moves into your application code. A relational database makes those relationships the model. Changing your mind later means remodelling data that now has users attached to it.
Where Backenly lands
PostgreSQL. Relational, with joins, foreign keys, constraints, and transactions, served over both a PostgREST grammar and a typed REST surface.
Who authors and applies a schema change, and what happens if one is wrong?
Every platform can change a schema. The differences are who writes the change, whether anything reviews it, whether there is a record afterwards, and whether a destructive operation can happen by accident. On most platforms this is a migration you write and run, with your pull request as the review. That is a good workflow when someone is reviewing.
Where Backenly lands
Changes go through one audited path. Schema-touching work takes a restore point before it runs, and destructive operations stop for human approval with the target named. You direct the change; the platform records and gates it.
What operates the backend after launch, on a week when nobody has time?
Most platforms report: metrics, logs, alerts, and your response. That is the normal and reasonable shape, and an experienced operator with good dashboards will beat any automation. The question is what happens in the weeks when there is no experienced operator with time, which for small teams is most weeks.
Where Backenly lands
A loop reconciles the backend against declared invariants on a schedule. A narrow set of additive repairs is applied automatically, anything touching authentication or anything destructive waits for a person, and the rest is reported with its evidence.
What can a coding agent do to your backend, and what happens on a bad turn?
If an agent is writing your code, its access to the backend is a real security boundary rather than a convenience feature. The useful questions are whether destructive operations are reachable at all, whether a key can be scoped down, and whether the constraint is something you configure or something the surface enforces.
Where Backenly lands
Twenty-three advertised MCP tools with destructive operations filtered out of the surface entirely, so they cannot be selected. Those requests become an approval queued for a person. Keys can be minted read-only, which withholds every write door including the natural-language one.
What does leaving look like, concretely?
Worth answering before you arrive rather than when you want to go. The specific things to check are whether the data comes out in a standard format, whether the access rules are portable or have to be rewritten, and whether the source is available if the managed service ever stops suiting you.
Where Backenly lands
Ordinary PostgreSQL, so pg_dump. The platform is Apache-2.0 and self-hostable including the autonomy engine, and the client packages are MIT.
What shape is the bill, and how does it fail?
Metered pricing and flat pricing are both honest and they surprise you differently: metered billing surprises you with an invoice, and a flat plan surprises you with a quota. Neither is a trick. Match the failure mode to which surprise your team can absorb.
Where Backenly lands
Flat monthly plans with visible quotas. A permanent free plan with one project, a $25 Pro plan, and a sales-led Enterprise tier. Capacity separates the plans; the repair loop is not metered on any of them.
Each of these is a real boundary rather than a roadmap item. If one is load-bearing for your product, that settles it, and the rest of this page is academic.
What Backenly is not for
A backend that is itself the product
If you are building a database, an exchange, a protocol implementation, or anything whose backend behaviour is the differentiator, a platform optimised for a common shape will be in the way. Write it yourself.
Offline-first mobile applications
There is no local persistence or offline sync layer. An application expected to work without a connection and reconcile later needs something built for that, and Firebase is the obvious example.
Stored procedures and SQL-function surfaces
Backenly exposes no SQL-function endpoint. Logic lives in functions triggered by database events, HTTP requests, or a schedule, so a codebase leaning on rpc()-style calls needs those call sites re-homed.
Preview environments per pull request
Branches exist and are scoped by API key, but nothing is wired into git. There is no preview-per-PR workflow, and auth, functions, and storage still resolve to main, so a branch is a data environment rather than a full copy of the system.
A frontend
Backenly is backend-only. It produces no interface, and it is not a substitute for an application builder. You bring the frontend, whether that is a framework, a visual builder, or a coding agent.
An arbitrary server-side runtime
Functions are shaped around events, HTTP, and schedules. This is not a general-purpose compute platform, and workloads that need one should use one.
Who should not switch
Your current platform is working and someone enjoys operating it
The main thing Backenly offers is that the operational work is done for you. If a member of your team wants that job and is good at it, you would be trading away control for a benefit you do not need.
You are mid-launch
A backend migration during a period when you need the product stable is a bad trade at almost any level of benefit. If the current system holds, let it hold, and revisit when nothing is on fire.
The real problem is the data model
Moving a poorly modelled schema to a new platform relocates the problem. If the pain is queries the model cannot express, fix the model. You may find you no longer want to move.
Ecosystem size is your binding constraint
If you depend on a large body of existing answers, third-party integrations, and engineers who already know the platform, a smaller one is a real cost. That is a rational reason to stay and it does not need justifying further.
You need something on the "not for" list above
Offline sync, stored procedures, preview-per-PR, or a general-purpose runtime. If one of those is load-bearing for you, this is settled and no amount of other advantages changes it.
What switching actually costs
There is no migration service on any plan. This is the real list of what you would be taking on.
- Moving the data
- Yours to do. pg_dump and restore between Postgres platforms; a remodelling exercise from a document store. There is no import tool and no migration service on any plan.
- Re-authoring access rules
- Policies are not translated. Row-level security is re-authored against Backenly's claim form, and Firebase Security Rules do not convert into RLS at all.
- Re-homing anything that was a SQL function
- rpc()-style call sites become event, HTTP, or scheduled functions. This is code, not configuration.
- Checking auth and storage call sites
- These are Backenly's own implementations. Common calls map across through the compatibility layer; anything provider-specific needs verifying.
- The cutover itself
- Planning the window, running it, and being ready to go back. Yours to own, on every plan.
- What you do not pay
- If you are coming from another PostgREST-backed Postgres platform, the query grammar is the same and the compatibility entry point means most client query code moves unchanged. That is the one part of this list that is genuinely cheap.
Comparisons against specific platforms
Once you know which criterion binds, the detailed pages go capability by capability and say where each alternative is stronger.
Questions about switching
Work out which of the criteria above is actually binding for you, then check whether Backenly is better on that specific one. If the binding constraint is ecosystem size, offline support, or a general-purpose runtime, the answer is no and you can stop there. If it is that nobody wants to own migrations, policy review, and incident response, that is the thing Backenly is built around.
No. There is a client-compatibility layer that lets a supabase-js frontend keep its query grammar, and pg_dump for the data, because both sides are ordinary PostgreSQL. Moving the data, re-authoring the policies, and running the cutover are yours on every plan, and nobody does them for you.
The free plan is permanent and includes one project, with the same repair loop and the same autonomy settings as the paid plans. The realistic test is to rebuild one non-critical part of your schema on it and see whether the workflow suits you before you consider anything larger.
It is PostgreSQL, so pg_dump gives you everything in a standard format that any Postgres will restore. The platform is Apache-2.0 and self-hostable if you would rather run it yourself. This is worth verifying on any platform you are evaluating, including this one, before you depend on it.
Test it on something real
One free project, kept permanently. Rebuild a non-critical part of your schema and see whether the workflow suits you.