Which CRM fits your team: Attio or Twenty?
Choose Attio if you want a managed SaaS CRM with no infrastructure to run, and choose Twenty if your customer data must stay in your own environment and your team can operate it. Most readers reach this decision through a seat or plan-limit renewal, a data residency requirement, or a plan to stop paying per seat as the number of objects and records grows. Attio prices per seat with object and record limits that vary by plan, so a growing data model can push you into a higher tier. Twenty's pricing page says the open source core can be self-hosted for free and that all plans include unlimited custom objects, fields, views and records, along with REST and GraphQL APIs and webhooks.
Attio fits teams that want the vendor to handle hosting, upgrades and availability, and that have no appetite for database administration. Twenty fits teams that need self-hosted data and unlimited objects and records, and that have the skills, or a partner, to run its stack. Twenty's backend uses NestJS with BullMQ, PostgreSQL and Redis, and its Docker Compose guide runs a server, a worker, PostgreSQL and Redis, asking for at least 2 GB of RAM because insufficient memory can crash processes. Confirm which Twenty features you need on the self-hosted core, because the pricing page ties SSO, audit logs and row-level permissions to paid plans.
Three decisions should drive the choice. First, list your hosting obligations: which regulators, contracts or internal policies govern where contact and deal data lives, and who must sign off on a new system in your environment. Second, measure your operations capacity: who would patch Twenty, back up PostgreSQL, monitor Redis and handle upgrades, and how many hours a month that takes against the seat and plan costs you avoid. Third, model your growth: estimate how many custom objects, fields and records your team will need over the next planning cycles, then compare the Attio plan you would need at that size with the self-hosting effort, using a written quote for each path.
Which option fits which scenario
This table maps common decision drivers to the platform that usually fits better, based on Attio's per-seat, plan-limited SaaS model and Twenty's self-hosted open-source core. Read each row as a starting point, then check the dependency note against your own environment, team skills and compliance obligations.
| Scenario | Better fit | Reason and what it depends on |
|---|---|---|
| Hitting plan limits on objects or records | Twenty (self-hosted core) | Twenty's pricing page says all plans include unlimited custom objects, fields, views and records, and the open source core can be self-hosted for free. Confirm current Attio plan limits in its pricing before comparing. |
| Customer data must stay in your own environment | Twenty (self-hosted core) | Self-hosting keeps records on servers you control. Whether this satisfies a residency or contractual rule depends on where you host and who has administrative access. |
| No one to operate PostgreSQL and Redis | Attio (hosted SaaS) | Twenty's Docker Compose guide runs a server, a worker, PostgreSQL and Redis, so someone must patch, back up and monitor them. If no internal owner exists, a hosted service or a DeployOpen retainer may be the practical choice. |
| Need for SSO and audit logs | Depends on plan and deployment | Twenty's pricing page lists SAML or OIDC SSO and audit logs under its paid Organization plan, and SCIM under Enterprise. Confirm which features apply to your deployment, and check Attio's SSO and audit options in its own plans. |
| Want a vendor to handle upgrades | Attio (hosted SaaS) | A hosted vendor applies platform updates for you. Twenty ships frequent releases, so a self-hosted team needs a regular upgrade routine, or a retainer that covers upgrades. |
| Existing team runs Node.js and PostgreSQL | Twenty (self-hosted core) | Twenty is a TypeScript application on PostgreSQL and Redis. Teams with that skill set take on operations more easily than teams without it. |
| Need for a fixed, predictable infrastructure budget | Depends on your environment | Self-hosting moves cost to servers, storage and administration, which vary by hosting model. Ask any provider for a written scope and an itemized quote before deciding. |
What the Twenty license allows and where the paid tiers begin
Twenty's core is mostly licensed under AGPL-3.0 with an additional application exception, according to the LICENSE file in the twentyhq/twenty repository. That means you can run the open source core on your own servers at no license fee. Files carrying an Enterprise license header fall under a separate commercial license, and the SDK and UI packages are MIT. Before you plan any work, check the file headers in the parts of the codebase you intend to touch, because the AGPL terms and the Enterprise header carry different obligations. Review the Twenty LICENSE with counsel and confirm the application exception covers your intended use.
The pricing page says the open source core can be self-hosted for free. Paid plans start with Pro at 9 US dollars per user per month, which the pricing page lists alongside unlimited custom objects, fields, views and records and REST and GraphQL APIs. Organization is listed at 19 dollars per user per month and adds row-level permissions, SAML or OIDC SSO and audit logs. Enterprise starts at 50,000 dollars a year and adds single-tenant isolation, IP allow-listing, SCIM provisioning and an SLA. Ask Twenty which of these controls your team needs, because choosing a paid tier is often driven by SSO, audit logging or row-level access rather than by seat count.
If you modify Twenty's AGPL-covered code and make it available to users over a network, the AGPL can require you to publish those changes under the same terms. Ask counsel to confirm how this applies to internal-only customizations, custom objects defined as code, and integrations that use the APIs without changing the source. Also ask whether any Enterprise-headed files are in your planned scope. Treat the license review as a gating step in the migration plan, since a decision made after customization is much harder to unwind.
Where customer data lives under each option
Attio is a hosted SaaS service, so customer records sit in the vendor's infrastructure under its terms. Twenty can run in your own cloud account or data center, which moves hosting, access logs and retention decisions inside your control. The cards below set out what changes with each option and what your team must confirm.
Hosting location and data residency
With Attio, contact, company and deal records are stored in the vendor's hosted environment, so residency depends on the vendor's regions and contract terms. With self-hosted Twenty, you choose the region and the account, and the database sits on PostgreSQL and Redis instances you operate. Ask Attio for its current data location options in writing, and confirm where backups and Redis queues are held for your own deployment.
Identity and SSO by tier
Attio's single sign-on availability depends on its plan, so check which tier includes SSO and provisioning before you rely on it. Twenty's public pricing places SAML or OIDC SSO in its Organization plan and SCIM provisioning in Enterprise, while the self-hosted core is free to run. Whichever you choose, confirm how your identity provider will map to workspace roles and how offboarding removes access.
Audit logging and role-based access
Twenty offers role-based permissions in its core, and its Organization plan adds row-level permissions and audit logs. Attio's permission model and audit trail should be checked against your needs, including who can export lists and who can see enriched fields. Self-hosting shifts log retention and log export to your own monitoring stack, so define how long you keep logs and who reviews them.
Compliance readiness you own
Your team owns the controls around the CRM: access reviews, backup testing, change records for upgrades and the evidence that each control operates. With a self-hosted Twenty deployment, the hosting environment, patching and database security fall to you or your implementation partner. DeployOpen prepares systems and evidence for assessments but does not issue audit reports or certifications.
Attestations you must confirm
Independent auditors and certification bodies decide whether a vendor or your environment meets a framework. Do not assume either product holds a specific attestation. Ask Attio and Twenty for their current reports and scope statements, and confirm that each one covers the services and regions you plan to use before you record it in your assessment.
What self-hosting Twenty on PostgreSQL and Redis involves
Self-hosting Twenty starts with the Docker Compose layout described in the Twenty self-hosting guide. The stack runs a server, a worker, PostgreSQL and Redis as separate containers. The server handles the GraphQL and REST APIs and serves the React frontend, while the worker processes background jobs. On the backend, Twenty is built on NestJS with BullMQ, which keeps its job queues in Redis, and PostgreSQL holds the workspace data, custom object definitions and records. Your team does not need to write application code to run this, but it does need someone who can operate a Node.js service, manage Postgres backups and monitor a Redis instance. The documented minimum is at least 2 GB of RAM, and the guide warns that insufficient memory can crash processes. Treat that figure as a floor, not a sizing decision. Before you choose a host, confirm current guidance for your expected user count and import volume, and load-test an import of your real Attio export in a staging environment. Also decide who owns the PostgreSQL backup schedule and how often you restore a backup to confirm it works, since Redis holds queued jobs that matter for automations and sync. Upgrades are the recurring cost to plan for. Twenty ships frequently: v2.48.0 was released on October 16, 2026, one day after v2.47.0, according to the Twenty releases page. Each upgrade needs a written test plan that covers custom objects, workflows, email and calendar sync and API integrations, plus a rollback plan that includes a database snapshot taken before the change. Decide in advance which release channel you will follow, who approves an upgrade and how long a staging environment stays in sync with production.
What drives the cost of each option
Attio and self-hosted Twenty charge for different things. One side bills per seat and pushes you up plans as data grows, while the other has no license fee for the core but moves cost to servers, upgrades and administration. Compare each component on both sides before you put numbers next to each other.
Attio seats and plan upgrades
Attio is priced per seat, and its object and record limits are set per plan. Recurring seat fees rise with headcount, and a growing record count or a need for more objects can force a move to a higher plan. Ask the vendor for the current limits for each plan, then model headcount and record growth over the contract term. Confirm which features sit behind each tier.
Twenty subscription tiers per user
If you use Twenty's hosted offering instead of self-hosting, Pro and Organization are billed per user per month, and Enterprise starts at an annual fee. Organization adds row-level permissions, SSO and audit logs, so the cost driver is which controls you need, not record volume. Ask whether your required controls sit on Pro or Organization before you assume the cheaper tier fits.
Free core and self-hosting servers
The open source core can be self-hosted without a license fee. The recurring cost is the infrastructure underneath it: a server or VM with at least 2 GB of RAM for the Docker Compose stack, plus PostgreSQL and Redis. Undersized memory can crash processes, so size for growth and plan for a larger instance as usage rises. Ask who provisions and pays for hosting in your cloud account.
Backups and recovery
Self-hosting moves backup responsibility to your team. You need regular PostgreSQL backups, tested restores, and copies of any uploaded attachments and configuration. This is partly one-time setup and partly recurring storage and testing effort. Define recovery targets before go-live, since no backup is reliable until it has been restored in a test.
Upgrades and monitoring
Twenty ships frequent releases, so upgrades are a recurring task rather than a one-time project. Each upgrade needs a staging test, a backup, and a rollback plan. Monitoring of the server, worker, database and Redis also recurs. Ask whether a retainer covers upgrades, testing and monitoring, and what it excludes.
Administration and migration effort
Administration time covers user provisioning, permissions, workflow maintenance and integration support, and it recurs for as long as the system runs. Migration from Attio is largely one-time: exporting objects and lists, rebuilding relations and automations, and validating records. Ask any implementation partner for a fixed scope that lists each deliverable, the migration steps, and what happens after go-live.
How a move from Attio to self-hosted Twenty proceeds
The sequence moves Attio's objects, lists and records into a Twenty workspace that your team runs on its own infrastructure, and ends with a cutover only after both systems have been checked against each other. Each phase has a clear output, so the team knows when it can move on.
Inventory objects, lists and automations
Before exporting anything, the CRM owner lists every Attio object, attribute, list view, relation, workflow and integration that the business depends on. Note which fields are enriched or calculated, because those may not export as plain values. The output is a written inventory that becomes the checklist for the rest of the move. Confirm the inventory with the people who run sales and customer success, since they will notice anything missing first.
Export each object and list view
An admin with export rights exports each object and saved list view from Attio, as described in the sibling export guide. Keep the files with their view names so they can be traced back to the source. Record which fields come out blank, especially enriched data from third-party sources. The output is a complete set of export files and a list of fields that need a different plan, such as re-enrichment or manual capture.
Plan for enriched and blank fields
Decide, field by field, whether a blank export value is acceptable, must be re-sourced from the original provider, or should be left out of the new CRM. Involve the data owners who rely on those fields for scoring, routing or reporting. The output is a short decision log that states the outcome for each affected field. Confirm with the enrichment vendor's terms what you are allowed to keep and re-use after you leave.
Stand up the Twenty environment
The platform team deploys Twenty in your own infrastructure using its self-hosting guide, which runs a server, a worker, PostgreSQL and Redis. Size the host against the memory guidance in the guide and set up backups, TLS, identity and access before any business data arrives. Test sign-in, role-based permissions and the email and calendar sync connections in a non-production workspace. The output is a working environment that passes a documented smoke test.
Recreate objects, fields and relations
Using the inventory, the CRM administrator rebuilds the custom objects, fields, views and relations in Twenty, which defines them as code. Map each Attio attribute to a Twenty field type and confirm that relations point to the same records. Keep the naming consistent so that imports and integrations match. The output is a schema review, signed off by the business owner, that shows every object and relation from the original system.
Import records and rebuild automations
The team imports the exported records in dependency order, starting with companies and people, then deals and activities, and checks row counts against the source files after each batch. In parallel, the workflow owner rebuilds automations, webhooks and email and calendar sync rules that Attio handled, and tests each one with sample data. The output is a loaded workspace with reconciled counts and a list of automations marked as tested.
Run parallel validation
For a defined period agreed in advance, sales and operations work from Twenty while Attio stays readable, and the team compares a sample of records, list views and reports in both systems. Check that API consumers, reports and user permissions produce the same results. The output is a signed defect log with each difference either fixed or accepted by its owner.
Cut over and retire Attio access
Once validation closes with no open high-severity items, the team freezes edits in Attio, runs a final incremental export and import, switches users and integrations to Twenty, and keeps a read-only export archive under your retention policy. Confirm with Attio's terms what happens to your data and when access ends. The output is a documented cutover record and a confirmed archive of the original data.
Questions buyers ask before choosing Attio or Twenty
How much effort does self-hosting Twenty take?
Setup is a one-time project, and upkeep recurs. The Docker Compose self-hosting guide runs a server, a worker, PostgreSQL and Redis, and asks for at least 2 GB of RAM because insufficient memory can crash processes. Setup covers provisioning the host, configuring the containers, placing the service behind TLS and access controls, and scheduling PostgreSQL backups. Upkeep covers applying upgrades, since Twenty ships frequent releases (v2.48.0 followed v2.47.0 by one day), and watching the worker and queue health. Your team needs Docker and Linux administration, PostgreSQL and Redis operations, and enough familiarity with the TypeScript, NestJS and React stack to troubleshoot. Test every upgrade on a staging copy before production.
How long does a migration from Attio take?
Duration depends mainly on the volume of records, the number of objects and list views to recreate, and the count of automations to rebuild. No standard timeline applies across Attio accounts, so the reliable answer comes from a written scope. Work drivers include exporting each object and list view, checking enriched fields that may export blank, recreating objects and relations in Twenty, importing records in test batches, and rebuilding workflows and email or calendar sync. Ask for a plan that lists every object, view and automation, the import rounds, and the cutover checks. Fixed-scope engagements are agreed in writing before work starts, so the timeline follows from that inventory.
Can a small team run Twenty without outside help?
A small team can run Twenty alone if one person has container, database and backup skills and can respond when something fails. The open source core can be self-hosted for free, so the main requirement is capacity: patching, monitoring, restores and upgrades still need someone accountable. Gaps usually appear during upgrades, database growth and incident response, not at first install. Outside help can be scoped in several ways: a one-time implementation with hardening and documentation, a handover to your staff, or an ongoing support retainer for upgrades and monitoring. DeployOpen plans, implements, hardens, backs up, upgrades and supports self-hosted platforms in your own infrastructure. Confirm with your team which of these tasks you will own before choosing.
What does the work need from our internal staff?
Internal staff need to make decisions and provide access, while an implementation partner does most of the build. Typical roles are:
- A data owner who confirms which objects, fields and records matter and signs off on the import checks.
- An administrator who grants access to the hosting account, DNS, certificates and the database backup target.
- A security reviewer who approves SSO, role-based permissions, audit logging and where backups are kept.
- A process owner who lists the workflows, email and calendar sync rules and reports that must be rebuilt.
Ask for the staff hours each role needs in the written scope, and agree who receives sign-off on each deliverable before work starts.
How do Attio plan limits compare with Twenty's unlimited records?
Attio prices per seat and sets object and record limits per plan, so growth in data can force a plan upgrade. Confirm the exact object and record caps for your tier on Attio's current pricing page, because those limits change and were not verified for this comparison. Twenty's pricing page states that all plans include unlimited custom objects, fields, views and records, plus REST and GraphQL APIs and webhooks. The limit you actually face moves to your infrastructure: database storage in PostgreSQL, memory for the server and worker, and Redis capacity. Plan that capacity against your record growth and backup window, and ask your implementer to size the host from your expected data volume.
Do we need Twenty's paid tiers to get started?
No. According to Twenty's pricing page, the open source core can be self-hosted for free. Paid tiers add hosting and features on top: Pro is listed at 9 US dollars per user per month, Organization at 19 dollars per user per month with row-level permissions, SAML or OIDC SSO and audit logs, and Enterprise from 50,000 dollars a year with single-tenant isolation, IP allow-listing, SCIM provisioning and an SLA. Self-hosting shifts cost to servers, backups, monitoring, upgrades and administrator time, and any implementation or support engagement is quoted separately from the written scope. Check the repository LICENSE file with your counsel, since Enterprise-marked files fall under a commercial license.
How to decide if your team cannot choose yet
Start by confirming your hosting obligations before comparing features. If a regulator, customer contract or internal policy requires that contact, deal and notes data stay in your own cloud account or data center, Twenty's self-hosted core is the only option in this comparison that meets that requirement on its own terms. Ask your legal and compliance leads to put the obligation in writing, including which personal data fields count and whether backups and logs fall under the same rule. Then count your current objects, custom fields, records and seats in Attio and check them against the limits of your current Attio plan and the next one up. Those counts show whether growth alone will force an upgrade, and they give you the volume a pilot must reproduce.
Next, check whether your team can run Twenty's stack. The self-hosting guide describes a server, a worker, PostgreSQL and Redis as the core services, and it asks for at least 2 GB of RAM. Confirm who will patch the database, rotate credentials, size Redis memory, configure backups and restore them in a test, and who is on call when the worker queue backs up. If nobody on the team already runs PostgreSQL and Redis in production, the administration effort belongs in your cost model, even if the license is free. Compare total cost by component: Attio seats and any plan upgrades, versus servers, storage, backup tooling, staff time for upgrades, and any paid support or retainer you choose to buy from a provider such as DeployOpen.
Before committing, run a pilot on a copy of a single object, such as companies or deals, and not on production data. Export that object from Attio, import it into a Twenty test instance, rebuild the fields and relations it depends on, and check that record counts, relations and at least one workflow match the source. Record how long the import and rebuild took and which fields lost data. Treat the result as your own evidence, since the outcome depends on your object design and volume. If the pilot passes and your hosting and administration checks are satisfied, you have a basis for a decision and a fixed-scope quote. If it fails on a field or relation, that is a finding to resolve before any migration begins.
How DeployOpen helps evaluate, implement or migrate Twenty
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For Attio vs Twenty, that means working from a written scope that covers your objects, lists, data and hosting environment before any work begins.
How we scope
- Inventory your Attio objects, list views, relations and automations to define what Twenty must reproduce
- Confirm hosting target, PostgreSQL and Redis operation, and the memory your Docker Compose deployment needs
- Agree in writing which enriched fields, integrations and email and calendar sync behaviors are in or out of scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed before work starts
How we build
- Deploy Twenty with its server, worker, PostgreSQL and Redis components in your cloud account or data center
- Recreate custom objects, fields, views, roles and workflows, and test them against a sample of exported records
- Configure email and calendar sync, SSO and permissions to match your existing access model
- Run security testing on the deployed application and APIs before records are migrated
How we hand over
- Document the architecture, configuration, backup and restore steps, and upgrade procedure for your team
- Provide a reconciliation report comparing record counts and key fields between Attio exports and Twenty
- Train administrators on object definitions, permissions, API use and day-to-day operations
- Deliver evidence and controls in a form your internal or external auditors can review
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Track Twenty releases and plan upgrades in a staging environment before production changes
- Keep backups, monitoring and capacity reviews running as your contact and activity volume grows
- Ask any provider, including DeployOpen, to confirm current Twenty licensing for Enterprise-header files
