SambaPOS a bit slow compared to Aloha

I came across a video, demonstrating a different POS system and I’m amazed by how responsive it is. There is almost no lag from human inputs.

Whenever I select a product or settle a payment on SambaPOS, there is always a 0.5s to 2s lag. I feel as if SambaPOS can be a bit more snappier. I’ve been told that my SQL db size is quite large. Does that play a factor to the problem or is SambaPOS naturally slow.

17+ GB sql db

Mine is instant no lag. Celeron 4 gig ram

17GB may be a factor. You can send us a Aloha screen. Does that have a same size of database ?
And if your Database server is SQLExpress, it’s file limit is 10 GB. There is an oddity.
And SQL Server Express have limitations. Like Memory. It’s use under 1 gb of memory.
All of these are factors.

Don’t throw the baby out with the bathwater,its your baby,
it would be easier for you to migrate to ALOHA than to compare the two.We have pledged our allegiance to samba from inception,you should cease from seeking attention because this is the wrong forum man


I don’t use Aloha and I don’t plan on using it ever.

What is the average size of a SambaPOS sql server? How do I reduce the size of my database?

I’m not sure what I said that warranted this sort of response…

You could upgrade to the Paid SQL server edition and have virtually unlimited db size support. Or you can clean it up after running a backup.


Not only fize size limitation. RAM usage was limited too

1 Like

And CPU/Cores …

I kept thinking, if the max size of an Express SQL db is limited to only 10 GB, why was mine 17+ GB? It turns out that the size of my db isn’t even close to 17 GB. It’s actually 4.8 GB.

I experienced this lagging in some setups, not sure why. One such system(my own former restaurant) runs on i5 still experience lagging. I believe it is settings of the WHOLE system including Samba, SQl, OS, network …, which renders it very hard to trace the real culprit.


Common to get a delay on first ticket and order after starting Samba as I believe caches are created.
Often overlooked is intensive reporting type expressions in repeated aspects like entity screens etc since it has to run same reports many times.
Best way to check if its a config/automation issue is to try a sample DB with just basic automation. I know my system is pretty heavy on order added automation which has an effect but do try and constrain rules themselves to be as tight as possible and not even start if not needed.
As you say there are many physical factors also, network itself can cause issues, poor/dodgy wiring dropping packets might not be noticeable for basic web browsing but soon mount up with constant requests and back and forth traffic. Good comparison for network isolation is obviously comparing speed on machine hosting the database rather than network linked. I mean if its slow on the SQL/server machine its unlikely going to be better of a networked terminal


Fast SSD and lots of RAM are your best upgrades by far. Especially a good SSD makes a big difference.

Defrag and re-index DB can help. There are maintenance tasks in SambaPOS for that.