Self-Hosted Performance (Recommended computer specs?)

Hi everyone!

New grist user here. I am currently using grist for web and may continue to do so. However, my team is also considering self-hosting (we’re too small for the enterprise level but hopefully we’ll get there someday).

To all the self-hosters out there, what kind of specs of a self-hosted computer are necessary to keep grist running very well?

My expected data:

  • 30 tables, most don’t have crazy complicated formulas (most are simple logic, lookups, and text fields)
  • Biggest tables would be: Customers (1000 rows), Equipment (3000 rows), Inventory Transactions (6000 rows), Work Orders (3000 rows), Activities (4000 rows), Contacts (6000 rows).
  • There would be a ton of linking and views for each of these main tables, the rest of the tables are either accesories or summarizing tables in some way.
  • Store all pdfs as links instead of direct attachments.
  • Would want to port forward eventually and access from the field.

Do you expect any capacity constraints running this setup? Currently we’re using a super cheap/ancient intel i5-6500 and 32 gb ram computer as our server computer. Do you expect any performance issues? At what point would you say we’d experience performance issues?

As well; is it more the # of tables, complexity of formulas, or amount of data that would take up massive CPU time?

Thank you :slight_smile:

P.S. Grist creators, you guys are superstars. I am porting my team from an ancient CRM/ERP and I was able to recreate 80% of its functionality in Grist within a few hours and make it 10x as intuitive as the previous product. I will be recommending and putting other companies on your products in the future x1000. Thank you!

Hello!

There is a page for hardware requirements:

I think that given the size of the tables, it is actually oversized. The CPU Time gomes from the formulars.
I had Problems with a lot of lookups (at least, that’s what I noticed). But that was more of a problem with how I did the lookup. That was back in the early days :smiley:

Because of the Enterprise version.
There was news that small businesses would have the opportunity to get it for free:
Pricing | Grist
(On the Bottom of the page is a short faq)

Greets
Philip

2 Likes

Hi @Brennan_Ukrainetz,

From my experience, you have plenty of headroom with the mentioned hardware.

We’re running a 15 MB database, containing 23,500 rows with many formulas as well. All this on a fairly modest rig:

  • i5-4690 @ 3.50GHz
  • 16 GB DDR3 1333 MT/s

The only thing is, when first loading the app page in the browser, I get a “Still working…” notice in the bottom right corner for about 8 seconds. But once it’s fully loaded, it runs fast.

And our prototype server was smaller than that:

  • i5 2500K
  • 8 GB DDR2

and ran fine for months.

As for “access from the field”, if it for “internal” use, I can’t help but recommend Tailscale. The free plan goes a long way.

1 Like

Hi there ,

I also run “Still working…” experience and discovered it was linked to my docker working on W11.
if so do not link the volume outside of container –> IO are very slow from the container to an external Windows volume especially for attached files.

Just for infomation

Hi @Sylvain_Page
Thanks for your input.

I’m not sure to follow. From my understating, any persisting data must live on a volume outside the container. Would you mind expanding on this?

Do you mean external hard drive or?

To be honest though, that few seconds delay isn’t something worth investigating since it has no effect once the app is loaded.

Hi Maclm,

I really appreciate the reply. That’s good to know that it can run well with pretty crappy specs. I just want to future proof things in case we have too much data - hopefully just buy a new i9 and fast RAM would do it (I would assume the CPU would be the limiting factor though since they run SQL Lite db and I think it’s limited to like 1 gb of ram or something?)

It also seems like people have come up with many ways of getting around the slow load times anyways with the $calc formulas where you just set that to true and only then does it recalculate everything.

I think this gives me enough confidence to go ahead with my plan. Thanks.

One more question - for the 23,500 rows you do have, how many columns would you say your tables have? Are we talking like 5-8 ish columns with some formulas in there as well?

I don’t know about such a hard limit. But I think RAM consumption is mostly a function of how many concurrent connections (users) you have.

As for the size of our DB, let’s see…
The largest table contains 107 columns and counts over 13,500 rows.
It has only 3 formulas, but references more than 40 other tables.

podman stats shows Grist uses between 0.06 and 0.20% CPU, and 0B RAM.
I doubt that RAM number though, as all containers are reporting zero. (Kinda weird.)

Looking at htop output, it’s hard to tell what’s related to what. But the whole server uses 2 GB RAM out of 16.

In other words, Grist requirements seems negligible compared to the OS itself. And you have more than plenty with 32 GB RAM!

Thanks for pointing out this $calc trick. I’ll look this up.

1 Like