top of page
Men with Calculator

MetaKarta Pricing

MetaKarta is a market disruptor, breaking the traditional pricing model that provides leverage for vendors as adoption grows at the expense of data leaders.

​

Explore MITI's approach and pricing components below.

explore​ 

MetaKarta Pricing Objectives

Our objectives are aligned with what data leaders want and are a product of years of experience learning what does and does not work.

MetaKarta Pricing Fundamentals

Want to understand our pricing?  Start by understanding the four fundamentals.

Concurrent users, not named users

We offer a concurrent user subscription model to give customers the freedom to maximize usage and unburden them from overpaying for named underutilized user seats.

No compute costs

We don’t believe in charging based on consumed compute processing.

Unlimited assets and objects

Our pricing always includes an unlimited number of metadata assets.  We don’t use caps, thresholds, or limits.

No charge for bundled metadata bridges

Each edition of MetaKarta includes specific metadata bridges (connectors) at no charge.  Each can be used for unlimited data sources, and the customer is entitled to all future enhancements.

Simple 1-2-3 Pricing

Explore our simple three-step pricing process below.

Pick a MetaKarta Edition

Use the comparison below to pick an edition based on your functional and metadata source requirements.

Feature_Grid.png

FAQ

These are the questions we are asked the most about our pricing.

  • Why are concurrent user licenses better than named users?
    Named user pricing models are the norm because vendors make more money from selling seats, even if each seat is only used a fraction of the time. It's a good model for vendors and bad for customers. We take the complete opposite approach. We sell concurrent user licenses because it helps customers get maximum value from MetaKarta. In the long run, its good for both us and the customer.
  • How many users can each concurrent license support?
    Concurrent licensing means that licenses are shared. When a user logs in, they reserve a license from the concurrent license pool. When they are finished, the license will be returned to the pool. Some also refer to this as a fractional use of each license. Much like a standard distribution curve, most will be light users who log in and out throughout the day. A minority of users will stay logged in for long periods. We use the terms 'producer' and 'consumer' to draw the distinction. Our general rule of thumb and good starting point is one concurrent producer license will support 4-5 heavy users, and one consumer license will support 8-10 light users. MetaKarta includes license usage monitoring and analysis tools so administrators can track average and peak license consumption to decide if/when they need to purchase more.
  • Why are MetaKarta producers and consumers better than writers and readers?
    Most vendors like to use the old distinction of a user as a 'writer' or a 'reader.' This fits well with their named user model and forces customers to purchase more expensive seats even if the average user only comments or provides occasional input. Along with this, they typically also offer low-cost or 'free' read-only users. The problem is that it blunts adoption by making it cost-prohibitive for broad participation. It also creates a potential bait-and-switch situation where a data leader agrees to the contracted price based mainly on the growth of 'free' readers, only to discover that the more successful they are, the more users want to write access. We decided to take a different approach with MetaKarta. A concurrent consumer license is not 'read-only.' It's a license that provides active participation in social commenting/curation, analysis, workflow, definitions, and more. With MetaKarta, data leaders get the best of both concurrent licensing to stretch their budget and licenses that permit meaningful participation. It's an approach that supports the adoption and growth of usage across an enterprise with price predictability.
  • Why do we not believe in consumption based pricing?
    Snowflake, AWS, and Microsoft Azure have championed consumption-based pricing. The idea is that customers pay based on storage and CPU processing cycles consumed. Consumption-based pricing is aimed primarily at transactional, AI, and data integration use cases. MetaKarta is a metadata-centric application and does not fit those use cases. Furthermore, most large enterprises already have consumption-based agreements with AWS or Microsoft. It would not make sense for us to 'double tax' our customers when they were already paying for the storage of MetaKarta metadata and the metadata harvesting processing. Instead, we simply charge a fair amount for the functionality provided for producer and consumer licenses.
  • How can MetaKarta bundle so many metadata connector (bridges) at no additional cost?
    Most vendors don’t create their connectors (bridges). They license them and package them into their product. In fact, most vendors license MITI's bridges, and this has been the case for decades. The result is that most vendors need to cover their OEM licensing costs, hence charging per connector. We own all our connectors, so we chose not to nickel and dime customers for connectors. Doing so creates a cost burden for harvesting metadata. That is a lousy tradeoff that threatens the long-term success of a program. Our focus is on users getting value from MetaKarta. That is why our pricing is centered around producer and consumer licenses.
  • Why is pricing using a count of metadata objects a bad idea?
    Some vendors price by the number of metadata objects/assets stored. First, that seems silly because most large enterprises already pay AWS or Microsoft storage and consumption-based fees. The vendor is double-charging the customer. Second, the costs of a vendor maintaining their software don't increase based on volume. If they do, there is something very wrong with the architecture of that product. Vendors that price based on volume have arbitrarily decided to 'tax' metadata growth. It's arbitrary because having more metadata does not equate to receiving more value from a vendor's product. They have disconnected the value received from what they charge. Ultimately, this forces organizations to choose what metadata not to manage and erodes the value of the entire program. We have made a different decision. We price based on producer and consumer concurrent licenses, not the number of objects MetaKarta manages. That allows organizations to store everything and emphasizes only charging for licenses because users benefit from them.
bottom of page