Friendly Clarification About Per-Seat Pricing

[altrsadmin]

Hello, this doesn’t quite make sense—please see:

I’ve installed the free self-hosted plan and I’m currently able to add multiple users, including assigning creator roles (in my case, just two). The rest are all our clients (a common use case), meaning they don’t access the system directly—they only interact via forms or submit data, without creating anything.

This setup is already more than sufficient. I’d be happy to pay for a self-hosted license for my instance, as a way to support the project and continue testing its features. However, a model where I end up paying significantly more than the cloud version per user on self-hosted doesn’t make much sense.

Did I understand correctly? Would I need to pay per seat even for viewers and editors?

Wouldn’t it make more sense to offer a one-time fee—say, $20—for a license tied to my self-hosted instance? That way, I could continue using the system with my current setup while supporting the project financially. It feels like a fair and sustainable model, especially for small teams or use cases where most users are passive participants.

[philibe]

👍

[altrsadmin]

@tea-artist Hello, friend! Please help us understand the pricing — we're eager to move the project forward!

[bytebone]

Not long ago, self-hosted pricing was offered on a per-instance basis. I still have the "20$ per instance per month" pricing page cached in my browser, only by this comment I found out that self-hosting is now equally expensive as the cloud offering, which is an utterly insane demand to make.

I also cannot find where one would even buy the selfhosted license. It is advertised on the public website but apparently not available through the purchase page. We rolled this app out today under the assumption to have the flat instance cost available to us, so learning this now is extremely frustrating. This makes Teable one of the most expensive providers for this that I've seen during my research.

[altrsadmin]

I’ve also been waiting for more than 30 days. Apparently, this doesn’t seem to be a topic of interest to respond to, but I’ve been quite disappointed since I’m an enthusiast of the project. I hope that @tea-artist can reply to us, or that the team in general reconsiders the policy.

=(

[altrsadmin]

Friends, if you could upvote the topic so it gains more relevance, it would be very much appreciated!

[tea-artist]

Hi @altrsadmin,
Thank you for your thoughtful feedback and for supporting Teable! Let me clarify how our self-hosted pricing works:

1. Form submissions don't require seats
   You're absolutely right about your setup. When external users (like your clients) submit data through forms, they don't need to register or create accounts in Teable. This means you don't need to pay for these form participants - they can interact with your bases through forms without counting toward your seat count.

2. Current pricing model
   Our current self-hosted pricing is based on the number of registered users - any user who creates an account and registers in the system. According to our pricing page, you pay per registered seat, regardless of their role (viewer, editor, or creator).
   In your case with just two registered users and multiple clients submitting via forms, you would only need to pay for those 2 registered accounts. Your clients who only interact through forms without registering don't count toward your billing.

3. Future considerations
   We absolutely hear your feedback about more flexible pricing models for self-hosted deployments. We're actively considering more tiered billing mechanisms that better reflect different use cases and roles - especially for teams like yours where most users are passive participants. Your suggestion about alternative licensing models is valuable input as we evolve our pricing structure.

[altrsadmin]

Hi @tea-artist
,
First off, thanks so much for your attention and thoughtful reply. I’d really appreciate it if you could genuinely consider what our colleague mentioned earlier — there’s already a precedent for instance-based pricing models. Right now, tools like Baserow and NocoDB are widely adopted, especially in setups like N8N.

In practice, the use of these platforms — or even the free version of TEABLE — is likely to continue. So positioning TEABLE as the more expensive alternative might end up limiting its long-term growth.

I truly believe that adopting a self-hosted, per-instance pricing model could be a game-changer. It would also help drive the development of official N8N nodes and other integrations. TEABLE stands out with its impressive performance and UX compared to the rest. And considering we already have BYOK and the infrastructure in place, it doesn’t seem unfeasible at all — in fact, it wouldn’t generate any apparent costs, only revenue. Right now, we’re using the free version and still getting fewer features than other solutions.

[bytebone]

When offering a cloud service, its price has to cover development cost as well as all hosting cost (storage, compute, networking, maintenance). When a customer chooses to selfhost the software, all of the cost from the latter category are carried by the customer already. They only owe you (the developer) a payment for the past and future development time. Therefor, it is completely off-the-rails to ask for the same price for a selfhosted environment as in the cloud environment. It also makes no sense to employ per-seat licensing, as the amount of seats in the selfhosted environment makes zero difference to your own cost or workload.

Imagine a small company with fixed 18 people, but frequent on- and offboardings due to on-demand freelancer hirings and short-term employees. Due to the frequent change in users, they require the user admin panel, which is locked behind the subcription. And since the amount of seats on a selfhosted license cannot be changed after the fact, this small company would have to estimate their highest possible employee count at any future point in time, lets assume a max of 25 people, and then pay ludicrous $ 6.000 per year - TO DELETE USER ACCOUNTS!

In no universe would this company license Teable to get access to a feature this simple. And even if they did, Teable would not provide this company a boost in efficiency so large that this fee would be remotely reasonable. They would easily spend $ 600 a year on an unlimited (seats, data, no support) instance license, but with this pricing model they'll simply stay on the free plan or purchase another product. Companies like this are not rare. You're heavily limiting your own growth potential by expecting sums this large.

[fpichardom]

When offering a cloud service, its price has to cover development cost as well as all hosting cost (storage, compute, networking, maintenance). When a customer chooses to selfhost the software, all of the cost from the latter category are carried by the customer already. They only owe you (the developer) a payment for the past and future development time. Therefor, it is completely off-the-rails to ask for the same price for a selfhosted environment as in the cloud environment. It also makes no sense to employ per-seat licensing, as the amount of seats in the selfhosted environment makes zero difference to your own cost or workload.

Imagine a small company with fixed 18 people, but frequent on- and offboardings due to on-demand freelancer hirings and short-term employees. Due to the frequent change in users, they require the user admin panel, which is locked behind the subcription. And since the amount of seats on a selfhosted license cannot be changed after the fact, this small company would have to estimate their highest possible employee count at any future point in time, lets assume a max of 25 people, and then pay ludicrous $ 6.000 per year - TO DELETE USER ACCOUNTS!

In no universe would this company license Teable to get access to a feature this simple. And even if they did, Teable would not provide this company a boost in efficiency so large that this fee would be remotely reasonable. They would easily spend $ 600 a year on an unlimited (seats, data, no support) instance license, but with this pricing model they'll simply stay on the free plan or purchase another product. Companies like this are not rare. You're heavily limiting your own growth potential by expecting sums this large.

I feel the same frustration. I brought up the issue of the limitation on listing and deleting inactive users in the self-hosted version on Discord; a couple of others agreed with me, but we never received an official response. I wrote:

"I'm now just starting to test Teable as I am comparing different solutions to use personally and potentially for my team later on. It is looking pretty promising and I really like the direction the project is going, but I'm surprised about the lack of simple managing option for users, at least in the free self-hosted version. As far as I am aware, as admin, in the free self-hosted version, I can't list the users that are signed up or delete an user if inactive or if it as a malicious/unwanted signed up. It is OK to put complex administration under a paid plan but I feel at least those two elements I mentioned should be still in the category of basic admin."

[garyli27]

@altrsadmin @philibe @bytebone @fpichardom

Thanks for the detailed feedback — just sharing a quick update on our side.

We’ve recently updated our pricing and seat-counting rules, and one change directly addresses the concern you raised:

• Seats are now counted only for collaborators with Editor-level access or higher (Owner / Creator / Editor).
• Viewers and Commenters are free, which significantly reduces the need to over-provision seats for user admin and frequent onboarding/offboarding.

This clarification is now reflected in our pricing FAQ.

If you’d like to review the full, up-to-date explanation, you can find it in the FAQ section at the bottom of our pricing page:
👉 https://teable.ai/pricing

Thanks again for taking the time to share your perspective — we appreciate the continued engagement from the GitHub community.

[altrsadmin]

Hi!

Thanks for the response and for being transparent about the pricing model.

I understand the rationale behind it and fully recognize the ongoing value of Teable’s development. That said, from the perspective of someone running self‑hosted environments in production, the per‑seat model remains a sensitive point.

In self‑hosted scenarios, all infrastructure, scalability, security, backups, and operational costs are already fully handled by the customer. In this context, the number of users does not represent a direct incremental cost for the vendor, as it does in a SaaS model. As a result, per‑seat pricing introduces friction that isn’t necessarily aligned with actual cost or perceived value.

While I do appreciate the availability of viewers and commenters, limiting editors — who in practice are often internal department users simply updating data or changing the status of a single row, with no structural creation involved — leads us back to the same original problem.

I’m not being inflexible or overly critical, but looking at this in practical terms: as a developer or consultant, I can’t create a base and make it available for users to minimally operate it. Even a simple task list would not allow users to mark an item as completed, since that action requires editor permissions.

In our specific case, we operate environments with temporary users, automated integrations, and administrative needs that require access to the admin panel but don’t justify a recurring per‑user cost. This ends up limiting adoption or forcing artificial access decisions, which isn’t ideal for either the customer or the product.

I keep emphasizing this point: the pricing discussion exists precisely because there is genuine interest in using Teable.

Considering a different metric for self‑hosted pricing — whether by adjusting the fee structure or even introducing a single fee for the space owner with all other users included — would be a brilliant path forward. In my view, this would increase overall revenue and position Teable as the undisputed leader in cost‑benefit for organizations willing to pay for at least one self‑hosted license.

That said, I appreciate the openness to discussion. The product itself is solid, and this conversation only exists because there is real intent to adopt it at scale!

If there’s any way for us to contribute more, please let me know!

PS: I’d also ask you to consider the current landscape, with the rise of vibe coding and the rapid growth of AI‑driven no‑code and low‑code tools. Since starting this discussion, I’ve already implemented small databases using Next.js and React, with a client‑facing frontend and no practical user limits, backed by a Supabase project costing around 15 dollars, where I can support an almost unlimited number of instances and users. In this context, the question becomes unavoidable: why would I pay per seat here?

[garyli27]

Hi @altrsadmin

Thanks again for the thoughtful and constructive feedback. It’s genuinely valuable and has helped us re-examine our self-hosted pricing approach.

From our side, there are a few core considerations:

1. Value-based, not cost-only pricing

For self-hosted Teable, we price primarily based on the value delivered, not just infrastructure cost. One user enables one unit of productivity; more users create proportionally more organizational value. Especially in larger teams, where collaboration, security, governance, project execution matter more, the value Teable provides scales with usage.

2. Low entry barrier and real cost savings

For most teams, the seat-based model is actually more cost-effective: with just one seat ($20/month), you can unlock the full Teable self-hosted capability and run it in production, rather than paying hundreds or thousands of dollars upfront. This keeps the entry threshold very low while giving you the complete Teable feature set.

From a cost perspective, self hosted differs significantly from cloud, so we invest additional engineering work, deeper support, and detailed deployment guidance. This means you can run Teable in production without having to build and maintain a lot of foundational work yourself, which reduces overall engineering and operational overhead.

3. Self-hosted is effectively a separate product

Self-hosted development is, in many ways, equivalent to building a second product. Pure development cost alone is easily 1.5× or more compared to a cloud-only offering.

In real deployments — especially high-availability Kubernetes setups — it’s common that a successful rollout requires dedicated time from both a support engineer and a developer on our side. Early on, this cost is often even higher.

We need to ensure that this model remains economically sustainable, so we can continue to invest in better stability, features, and long-term support.

---

This is the thinking behind our current approach. We fully understand why this topic is sensitive, and we truly appreciate the open discussion — it exists precisely because there is real interest in adopting Teable at scale.

Thanks again for the candid feedback.

[altrsadmin]

Thank you for the quick response. I appreciate the attention given to the community and the honest feedback — it’s through this kind of openness that we’re able to understand things more clearly.

There’s no doubt that in any business the 80/20 rule applies: 80% of our focus goes into our core activity — in our case, software development — and the remaining 20% is what truly moves the needle. Having a solid pricing strategy, combined with intuition and persistence in the founders’ values and principles, is essential. For that reason, this will be my final interaction before marking the topic as resolved.

A product in the same segment follows a fair‑price policy where it charges per seat up to eight users, and after that it becomes a fixed price with unlimited users. This could make sense for Self‑Host as well, potentially increasing the ticket value. As I’ve mentioned repeatedly, moving from unlimited users on the free plan to a per‑seat model on Self‑Host — especially considering that the AI engine is BYOK — is understandably difficult to balance from the buyer’s perspective.

This becomes even more challenging in emerging countries where the exchange rate can reach 6:1 against the dollar, as is the case in Brazil. Because of that, the current pricing model doesn’t fit my use case, so I’ll decline the upgrade for now.

Once again, thank you for the feedback. I’ll continue following and supporting the project however I can as an enthusiast.

Wishing the Teable team continued success!

[garyli27]

Hi @altrsadmin could you send us an email for letting us know your use cases? support@teable.ai