If you’re comparing dForge and Kintone, you’re looking at two no-code platforms that both take data seriously. Kintone is a capable, mature platform with granular permissions, built-in collaboration, and a large customer base, and we’re not going to understate it. This is a closer comparison than most.
The honest difference is structural, and it’s about ownership. Kintone is a no-code platform for building business apps and collaborating around them, in the cloud. dForge is an extensible operational platform you own and can self-host. Both let you model data and control access well. The question is whether you want a collection of apps in someone else’s cloud, or one operational platform that’s yours.
The short answer
Choose Kintone if you want business users to build apps quickly without code, you value built-in collaboration around your data, and granular permissions matter to you. For teams that want a friendly, capable app-and-collaboration platform in the cloud, Kintone is a strong, proven choice.
Choose dForge if you want one unified operational platform rather than a set of linked apps, you need to own and self-host the system, and you’re building something that has to scale past per-app limits and outlive the people who built it. dForge is the operational platform underneath — built on a real relational schema — not a collection of apps on top.
At a glance
| dForge | Kintone | |
|---|---|---|
| What it is | One unified operational platform for your whole operation — owned and self-hostable | A no-code app-and-collaboration platform |
| Data model | One PostgreSQL schema with true relations and constraints | A collection of apps, each its own database, linked by lookups |
| Record limits | No per-table cap; scales as a real database | Around 50,000 records per app; performance slows beyond |
| Permissions | Row, column, and folder-level, enforced on every request | Space, app, record, and field-level — genuinely granular |
| Audit | Built in — every write logged with before/after snapshots | Audit logs plus change history with revert |
| Collaboration | Operational, not social | Built-in spaces, threads, and conversations |
| Deployment | Managed cloud or self-hosted; isolated database per customer | Cloud service |
| External users | No — internal operations only | Guest accounts for external collaboration |
| Data ownership | You own the PostgreSQL database; exportable, self-hostable | Apps and data live in Kintone’s cloud, in its format |
| Pricing shape | Per-seat tiers (cloud) or contract license (self-hosted) | Per user, five-user minimum; guests billed separately |
The core difference: an app platform vs a unified operational platform you own
Kintone’s model is that business users should be able to build the tools they need. You assemble apps with drag-and-drop, each app holding its own data, and Kintone adds workflow, granular permissions, and a layer of collaboration — spaces, threads, conversations — around them. For a team that wants to replace scattered spreadsheets with friendly, governed apps in the cloud, that’s a genuinely good fit.
dForge starts one layer deeper, and it starts from ownership. You model your domain in metadata, and dForge generates a single real PostgreSQL schema with true relations and constraints, not a set of separate app-databases stitched together with lookups. Roles, permissions, lifecycle states, and a full audit trail are primitives, and the whole system can be exported and self-hosted.
So the honest framing is: Kintone answers “let our team build and collaborate around apps, quickly.” dForge answers “give us the unified operational platform our business runs on, and let us own it.”
Where Kintone is the better choice
We’d rather you pick the right platform than switch and regret it.
- You want granular permissions out of the box. Kintone’s space, app, record, and field-level controls are genuinely strong, and they’re a real strength, not an afterthought. This is one area where Kintone matches the kind of governance dForge is built around.
- You want built-in collaboration. Kintone’s spaces, threads, and conversations let teams discuss work right next to the data. dForge is operational, not social, and doesn’t try to be a collaboration hub.
- You want business users building apps fast. Kintone’s no-code, drag-and-drop builder is friendly to non-developers, with templates and free proof-of-concept help to get started.
- You want a mature, proven platform. Kintone supports a large base of organizations across many industries, with strong support resources.
- You need lightweight external collaboration. Kintone’s guest accounts let outside people work in specific spaces. dForge is internal-operations only and has no external end-user authentication.
If those points describe you, Kintone is likely the better fit, and that’s a fine outcome.
Where dForge is the better choice
- You want one unified operational platform, not a collection of apps. dForge generates a single PostgreSQL schema where everything relates natively. Kintone’s data lives in separate apps linked by lookups, which works, but means your operation is a set of connected apps rather than one integrated platform.
- You’re going to outgrow per-app limits. Kintone caps records per app at roughly fifty thousand, and performance slows as you approach it. dForge generates a real database with no such per-table ceiling, so growth doesn’t force you to split data across apps.
- You want to own and self-host the system. Kintone runs as a cloud service; your apps and data live there, in its format. With dForge, your application is a PostgreSQL database plus its metadata, which you can export, inspect, and self-host on your own infrastructure.
- You need isolation per customer. Each dForge customer gets a dedicated, isolated database rather than a tenant on a shared cloud platform.
- You’re a founder building a domain-specific product. dForge gives you the production backend — data model, roles, audit, API — with a module system and AI-generated metadata via an MCP server, to build the part that’s unique to you. Kintone is built for an organization’s internal apps and collaboration, not for being the backend of a product you ship.
One schema, or a collection of apps
This is the distinction that doesn’t show up in a quick demo but shapes everything you build on top.
In Kintone, the unit is the app. Each app has its own data, and you connect apps to each other with lookups and related records. For many use cases that’s perfectly workable, and the friendliness of building one app at a time is part of why Kintone is easy to adopt. But as your operation grows, you end up with a set of linked apps rather than one coherent database, and the relationships between them are lookups layered on top rather than true relational structure underneath. The per-app record ceiling reinforces this: scale tends to mean more apps, not a bigger database.
dForge inverts that. You model the whole domain once, and dForge generates a single relational schema with real foreign keys and constraints. CRM, inventory, and operations data don’t live in separate apps that reference each other; they’re tables in one database that relate natively. The data model is the durable asset, and it’s built to be the operational platform your business runs on, not a collection of tools.
Data ownership and the day you’d rather not think about
With Kintone, your apps and data live in its cloud, in its format, on its plan. For most teams that’s fine, until a pricing change, a compliance rule, or simply the realization that the system your business runs on isn’t yours to hold.
With dForge, your application is a PostgreSQL database plus its metadata. You can back it up, export it, move it, and self-host it. And if a subscription or license ever lapses, dForge moves to read-only rather than locking you out, so your data stays fully readable and exportable. Access is never destroyed.
Pricing: per seat, with different ceilings
Kintone prices per user, with a five-user minimum and no setup fee, and guest accounts are billed separately. It’s accessible to start, and for small-to-mid teams the per-user cost is reasonable. The constraints to plan for are structural rather than financial: the per-app record ceiling, the modest data-import caps, and the fact that it’s a cloud service in Kintone’s format. (Verify current Kintone figures before publishing — pricing and limits change.)
dForge’s cloud edition is priced per seat, in tiers, and the self-hosted edition is licensed by contract. The governance that’s strong on both sides — granular access control and a full audit trail — comes standard here too, and what you also get is an operational platform you own — backed by a real database: no per-table record ceiling, and the option to run the whole system yourself. Which fits depends on whether you want an app platform in the cloud or an operational platform you hold.
Which should you choose?
- Pick Kintone if you want business users building apps fast, you value built-in collaboration and granular permissions, and you’re happy with a capable cloud platform.
- Pick dForge if you want one unified operational platform you own and can self-host, with no per-app record ceiling and the structure — a real relational schema underneath — to be the platform your business runs on for years.
The honest test: if you want a friendly platform to build and collaborate around apps, Kintone is a strong fit. If you want one operational platform that’s yours, scales on a real relational database, and is built to last, that’s dForge. If you’d like a second opinion on which side of that line you’re on, get in touch — we’ll tell you honestly when Kintone is the better call.