How Thorlux Lighting Scaled IoT Sensor Data from Hospitals and Airports to Mission-Critical Scale on Tiger Cloud

A four-person engineering team moved from a data corruption crisis to handling 25,000 sensor records per second with Tiger Cloud on AWS.

Thorlux Lighting, part of the F.W. Thorpe plc group, designs and manufactures professional lighting systems deployed in hospitals, airports, and other critical infrastructures worldwide. After a trial, Thorlux moved its mission-critical SmartScan IoT platform into production on Tiger Cloud, migrating from a failing MariaDB infrastructure that had suffered data corruption and blocked its roadmap progress for 18 months.

About Thorlux

Hospitals and airports rely on emergency-lighting systems that function during power failures, network outages, and disasters. Regulatory bodies require records of all emergency-light testing for compliance audits; a legal obligation that extends decades. An airport's emergency luminaires must prove they were tested monthly; and a hospital must document every single-light test and result. Failure to produce these records on demand creates liability and regulatory risk.

Traditional lighting systems do not collect data, but Thorlux's SmartScan platform changes that. Each networked luminaire contains wireless-enabled sensors that report energy consumption, occupancy status, and emergency-test records to a central database every few seconds, 24/7. The platform's analytics dashboards and compliance-certificate generation turn that raw data into actionable insights for facility managers and auditable proof for regulators.

SmartScan's team is four people: strong application and web developers, but without database or infrastructure expertise. They built version one on MariaDB with self-managed cloud infrastructure. Pilot workloads ran fine, but production brought problems and a level of scale and complexity that the self-managed MariaDB infrastructure couldn’t handle.

The Challenge

By early 2023, Thorlux's database had grown to 500-600 GB, a legacy of months of high-frequency sensor ingestion and seven years of compliance records. The MariaDB instance began to show strain. In May 2023, disaster struck: a disk corruption event damaged nine tables, three of them substantial. The team entered damage-control mode; the three largest tables remained in recovery, months after the incident.

The disk corruption crisis forced a difficult truth into the open: SmartScan Gen 2, a significant product roadmap item, had been delayed 18 months because the team could not trust the back-end database to remain stable under load. Every regression test, every feature build, every deployment carried the risk that database corruption could appear unannounced. The team did not have the expertise to prevent or recover from such incidents quickly.

The data retention challenge further compounded the problem. Emergency-lighting records carry a legal requirement of up to 27 years. That is not backup retention; that is live, queryable data that customers and auditors need to access. Self-managed infrastructure meant Thorlux had to provision storage for decades of continuous data growth, with no clear path to cost control.

Why Tiger Cloud and Why Now

In 2021, Thorlux commissioned an external database audit that recommended a fundamental shift: migrate from a relational schema built for point-and-transaction workflows to a time-series database optimized for high-frequency, immutable sensor data. The auditors noted that Thorlux was "transacting lots of data for no reason" and the schema was storing every sensor reading as a separate transaction, with minimal compression and inefficient indexing.

That audit led Thorlux to TimescaleDB. But the team faced a decision: self-host TimescaleDB on their own AWS infrastructure, or adopt a managed service? Carl Bland, Head of IT at Thorlux Lighting and Steven Lewis, Web Systems Manager at Thorlux Lighting made sure to evaluate the trade-off. "We don't have a lot of skills around large data management," Bland noted. "Our Web team is good at developing websites, but not so much at managing the back-end infrastructure." The team could not commit engineers to database operations, WAL management, disaster recovery, or handling corruption if it happened again.

Tiger Cloud on AWS was the obvious choice. A four-person team without infrastructure expertise couldn't maintain production MariaDB safely. Tiger Cloud removed that burden entirely. Tiger Data handles the infrastructure, backups, encryption, and high-availability read replicas. The team was free to focus on building SmartScan instead of managing databases. They trialed it first, then moved production workloads.

The SmartScan Stack

SmartScan's data flow begins at the edge. Hundreds of networked luminaires installed across customer sites transmit sensor readings via 3G and wireless networks every few seconds. Those messages arrive at Thorlux's ingestion layer, where PHP batch scripts validate device identity, apply calibration thresholds, and transform raw readings into normalized records. The scripts feed into Tiger Cloud, where hypertables store the continuous time-series data: daily energy data, occupancy events, emergency test records, and others. Standard PostgreSQL relational tables (rf device, customers, sites) migrated directly from MariaDB, and coexist in the same database. Customer-facing dashboards query Tiger Cloud directly via a web API layer; compliance-certificate generation also queries Tiger Cloud to produce audit-ready reports on demand.

A critical architectural detail: Tiger Cloud is deployed in the EU with AWS PrivateLink, ensuring data residency compliance regulations for European customers and hospital networks are met. The deployment supports approximately 20,00-25,000 sensor records per second at peak ingestion.

Thorlux's schema takes full advantage of TimescaleDB's compression and multi-dimensional partitioning. Hypertables are configured with monthly chunks, segmented by device ID, and ordered by timestamp descending. This configuration balances query performance (searches by device and time window hit the fewest chunks) against write performance (inserts cluster by device, reducing index fragmentation).

One critical migration change was how Thorlux writes data. The original application code used a web framework ORM to insert rows one at a time; a pattern that works at small scale but becomes catastrophic at 20,000 records per second because each single-row insert is a network round-trip to the database. Thorlux rewrote the ingestion layer to batch records into bulk inserts, dramatically reducing network overhead and database CPU pressure. That change alone revealed hidden bottlenecks in the application that had been masked by database latency.

For long-term retention, Thorlux uses Tiger Cloud's tiered storage. Data older than approximately 2 years automatically moves to S3, where it costs 8-10 times less per gigabyte than hot storage, yet remains queryable as if it were in the primary index. That capability is essential for a system with 27-year data retention requirements: without tiering, a single customer's historical archive would cost thousands per month.

Results

• Compression delivered real savings, with tradeoffs: Thorlux achieved compression ratios of 98% on raw sensor data using Tiger Data's native compression. However, maintaining query performance required a different approach: segmenting compression by device ID. This reduced the effective ratio to 50-60%, but still cut storage costs roughly in half compared to uncompressed storage. Steven Lewis, Platform Engineer at Thorlux, explained the tradeoff: "We have seen compression rates of 98%. But to keep the queries performing well we need to segment the compression.”

• The migration revealed hidden application bottlenecks: Moving to Tiger Cloud exposed a performance problem in the application layer that the team hadn't anticipated. One ingestion routine was executing 8,000 separate database queries to insert a single report. Under the high-latency remote database, this process took minutes. When Thorlux rewrote it as a single batched insert, the same operation completed in seconds. Lewis attributed this discovery to the clarity that comes with a fresh architecture: "It's actually helped us find bottlenecks and problems in our application by switching to Tiger Cloud. One of our processes is doing 8,000 queries to insert one report. If I send one query that inserts all of that data at once, it's going to massively speed things up."

• Stability removed the biggest roadblock to SmartScan Gen 2: Six months into the Tiger Cloud production run, the team's confidence in the platform was clear. The back-end was no longer a source of uncertainty. With a fully managed, high-availability database handling the operational load, the product roadmap could proceed without delays for stability concerns.

Lewis summed up the team’s experience with Tiger Cloud as overall very positive: "I'm really pleased with everything. The service from the help desk is great. How simple it is to create hypertables is very good. The control panel is really easy to use. We've asked a few questions to the support team and we've had very fast responses."

Looking Ahead

The team plans to grow the SmartScan user base, which means thousands more installations across hospitals, airports, and industrial facilities worldwide. At that scale, the architectural choice made in 2023 becomes the foundation of everything.

All data—historical compliance records, real-time sensor streams, customer metadata, application state—lives in a single PostgreSQL instance managed by Tiger Cloud. No split architecture. No separate time-series and relational systems to keep in sync. And critically, no surprises as they scale. With tiered storage handling the transition between hot and cold data automatically, growth doesn't trigger a crisis of rising costs or degrading performance. The data model doesn't require rearchitecting as the user base grows. It simply gets bigger. As Thorlux scales from tens of installations to thousands, the database architecture stays predictable. The operational model stays simple. The infrastructure bill stays manageable.