Pricing based on records rather than Storage

Knack Community
1

I may get an ass-whoopin here but I just wanted to echo my feelings about the way pricing structure works.

Currently for our database we have a stack of records but they take up relatively small amount of space.
(currently 51,091 records taking up just 18% of the allowed 10GB)

The basic the plan allows for 50,000 records 10GB.

We have had to take an add-on onto the standard plan taking us to 65,000 records in 15GB.

I really don’t know how everyone else has their data but to my way of thinking this method of charging leads to BLOATED PRIMARY RECORDS in a database rather than maintaining an even spread of data across the board.

For example:
We have a Soldiers record where we record basic information regarding him and his service.
But we need to expand it to show events during his service such as being wounded, notes regarding temporary duty with other units, copies of photographs, letters etc etc and items that may be lost in time.

BUT because we have unknown numbers of these sub items to link back they have to reside in their own file (and thus adding to the total number of records on the system).

We also like to maintain a record of what changes were made to the file, when and by whom. An audit trail if you will. And here’s where it blows your record count out of the ballpark.

It is just not possible to have a fully functional system with an audit trail for a database such as ours within the allowance of our the number of records.

I don’t really grasp why it is defined by the number of records and not the storage in the first place ?

What if I had a contacts list with over 100,000 names and phone numbers for next-of-kins contacts but the only data we have is name address telephone no. Such a minimum information database could consume perhaps 1-2% of the alloted storage space but exceeds the record allowance of a corporate rate ?

To my way of thinking no of records as the basis for charging is weird compared to the generous storage.

10GB for 50,000 records is equivalent to 2mb each record which for what is essentially a text based system is an extraordinary amount equal to around 2 million text characters per record !

(I think I have the maths right if I don’t I’ll go hide in the naughty corner).

And considering that graphic handling is not as great as it could be, strong probability that people are storing their images outside the database and using url reference like one-drive to display them.

I would seriously urge KNACK to reconisder setting record limits as a driver for pricing and instead address storage as the the main focus. I love knack but we are an NFP who rely on a small number of dedicated members for our funding and I feel records constantly poses a challenge to find workarounds to keep us within a reasonable cost.

This is MY opinion for what its worth. Corporate users may feel differently.

2 Likes
2

@RayWindlow47079, nice write-up!
You’re probably not alone in this thinking, and I’m sure the Knack team have had their own brainstorms on the best way to structure pricing.

I presume as a SaaS platform, there’s only a couple of ways you can charge out your product, each with their pros and cons:

  • Per record / storage (Knack, Airtable, etc)
  • Per user / unlimited records (Notion, etc)
  • By resource/workload usage (Bubble, etc)

Of the three, I think ‘per record’ provides the most transparency. Resource usage would be tricky to quantify as an end-user, and per user is super limiting for an app like Knack.

I’d love to see a world where Knack could at least increase the record limit for each plan, but they’d need to make it up elsewhere.

For yourself, there’d be coded ways to reduce record consumption by concatenating smaller records into one text field (e.g. record changes) and displaying those as normal in the front-end, but ideally it shouldn’t have to come to that.

1 Like
3

Hi Stephen and thanks for the encouragement.

There are limits to what can be concatenated together as well.

One such field we have requires generating a textual display showing a sdiers information and if he was taken POW what camps and countries he was held in.

That requires if then type handling which Knack doesn’t have.

Example
Guy taken POW spends 6 months in camp in Libya, 1 year at 1 camp in Italy, 4 months at a 2nd camp in Italy then 3 years at 2 different camps in Germany

To construct a meaningful dialogue meant creating multiple text fields to include
Libya
Libya and Italy
Libya Italy and Germany
Italy
Italy and Germany
Germany

To try and achieve it with just one field definition without if then means blank lines above and below as empty values can’t be suppressed from the output.

But it also means a lot of irrelevant text fields are generated across the board for many of which these fields totally do not apply. And for those that were POW only 1 of 6 circumstances applies.

It all about compromises and inventiveness but sometimes a good solution is out of reach.

I come from a true relational database background from 80s where multi valued fields and nested if then evaluations were possible programmatically as well as in dictionary (field) definitions. As most of our system is text based I miss the power I use to have to produce results

But given that, KNACK is perhaps the only system I have found for online databases which contains pretty much the full suite of functionality as well as a workable interface not requiring myriad of programming to support it.

Useful traits to have if you’re working with an NFP with tiny budget.

1 Like
4

Hi

I’m in agreement with Stephen but understand where you’re coming from Ray. We were in a similar situation not too long ago and whilst we find Knack good value based on their record count model, we were rapidly approaching the 50, 000 record limit and decided to look at where our records were concentrated and address the issue if possible.

We ended up doing as Stephen suggested and concatenated a lot of our old records (contact notes) into 1 text field for each contact and reduced our record count by almost 25%. Here’s the link to Callum’s Youtube video that we took the idea from.

Dean

2 Likes
5

Yeah, Knack definitely needs to upscale their record limits. I have a client that took me 6-months to convince to go to a SaaS environment. But, unfortunately I can’t use Knack. So I’m going with another platform where record limits are almost non-existent.

So just to give you an idea. This client has just barely under a million records currently and about a half-dozen users. That’s small by database standards. They hope to hire more people to use the system. But since this is a medical-legal app, it takes a minimum of a year to get someone up to speed. Anyway, under Knack’s current (annual) pricing, that would cost “$1249/month billed yearly”:

1249 X 12 = $14,988.00 annually!

That’s insane. Especially considering I could use any one of a dozen RAD tools (that I’m familiar with) where I could have millions and millions of records and dozens of users at no extra cost. But I do have a SaaS option that easily allows more than a millions records. Yes, they charge per user. But even a dozen users will be half the cost of Knack. This is too bad because Knack seems like it’s on the cusp of major improvements (Flows seems to be a great harbinger of that; although I haven’t had time to check out Flows yet). But the cost is prohibitive in any case.

Knack should revisit their pricing model and see if there’s a way to provide a more inviting and robust model to use their platform. I don’t think the current record limits are viable in the long term, maybe not even in the shorter term?

My 2-cents.

4 Likes