Comparison
vs. the competition
Feature comparisons are easy. The hard part is seeing what happens when you have a 20-year-old Oracle database and you need to change a screen at seven in the morning, before the warehouse shift starts.
| Feature | | Retool | Appsmith | Budibase |
|---|---|---|---|---|
| Hot deployment in production | Yes Native | No | No | No |
| UI generated from DB metadata | Yes Automatic | Manual | Manual | Manual |
| Multi-step business processes | Yes In metadata | In code | In code | In code |
| Native multi-tenancy | Yes | No | No | Limited |
| Enterprise Oracle / LDAP | Yes | Yes | Partial | Partial |
| On-premise | Yes | Enterprise | Enterprise | Yes |
| Open source | Coming soon | No | Yes | Yes |
| Migration from Versata/LAC | Yes Native | No | No | No |
| Base price /month | €0 | ~$550 | ~$480 | ~$50 |
Why not Retool
Someone has to draw every screen. For a database with 50 tables, that is weeks of work. e-cometa generates them automatically from the metadata.
A change in production requires publishing. In e-cometa the change is in the metadata database, so there is nothing to publish. The next user who opens the screen already sees the updated version.
Business logic ends up being programmed. Confirming an order, generating the XML or chaining a notification are queries and JavaScript that somebody maintains. In e-cometa a process is a sequence of steps in metadata, and it is corrected in production like a screen.
Pricing scales with editors. In enterprise settings with many apps, the cost of Retool takes off. e-cometa has flat pricing per deployment.
Why not Appsmith
Appsmith is the open-source alternative to Retool. The code is on GitHub and it can be deployed on-premise. But it shares the fundamental problem: the UI has to be built by hand.
Support for Oracle and legacy databases is limited, LDAP takes non-trivial configuration, and hot deployment does not exist. For a company with an Oracle database and corporate LDAP, it is not a practical option.
Why not Budibase
Budibase has the best price on the market and a solid open-source approach. It is a legitimate option for simple cases. Its limits: designed for forms over simple schemas, no native Oracle support, no migration path from Versata/LAC, and no real hot deployment.
“Isn't this just low-code?”
In a low-code tool, the vendor defines the model and your business adapts to it. Here the model grows with your business, it is yours, and the runtime that executes it is open-source code your team already knows.
The rule that keeps it that way: if a requirement shows up twice, it stops being bespoke code and becomes metadata. The model grows with every project, the bespoke code shrinks.
Why not generic low-code on a legacy database
Most low-code tools are designed to build on modern databases. If you have an inherited Oracle database, tables with legacy naming, or logic in stored procedures, generic low-code does not understand your schema.
e-cometa was designed from the start to work with real, complex, inherited schemas. The industrial distribution case, a migration from Versata on a decades-old Oracle database, is the proof that it works where others cannot reach.
The right question is not "what is cheaper?"
It is how much the development time you avoid is worth. A developer takes 3 weeks to build basic screens (≈ €6,000–9,000). e-cometa generates them on day one. With e-cometa there is nothing to pay back: the free plan does not expire.