Context: started a company that did essentially this about a decade ago. Haven’t looked back much. My data may be stale or just biased.
> We used old control software that spit out data in massive 10 GB CSV or TDMS files. After a long day and night of testing, no one wanted to go through all the work to review the data.
> We think Synnax is unique in that it provides a bridge between <lab/automation DAQ systems>
On the surface it seems like anomaly detection is still the hard problem, but you’re not setting out to solve it?
Time series databases are state of the art generally in finance, not in industrial/InfluxDB, so I don’t think saying you’re 5x influxSB on writes is going to persuade too many people, especially given the cost now for a terabyte of RAM. I’ll just move all of it to an in-memory database before I’ll take on the switching costs.
The thing I wanted was one solution for something that was always two: a properties/metadata database, and a separate time series database.
It seems to me like you are maybe building a level too low and could get a lot more value working on the problem that you say motivated you in the first place. It is hard because of all the context required to automatically detect anomalies, but I think that is why it is valuable to solve.
The value we had was we rolled in the data/cellular connection all the way down to the endpoint, so they could avoid IT integration, which was a big hurdle at the time. I don’t know if IT integration is still a hang up for your customers.
We found that visualization layers tended to reach down just far enough into the data intake world that it was really hard to sell just another tsdb.
> We used old control software that spit out data in massive 10 GB CSV or TDMS files. After a long day and night of testing, no one wanted to go through all the work to review the data.
> We think Synnax is unique in that it provides a bridge between <lab/automation DAQ systems>
On the surface it seems like anomaly detection is still the hard problem, but you’re not setting out to solve it?
Time series databases are state of the art generally in finance, not in industrial/InfluxDB, so I don’t think saying you’re 5x influxSB on writes is going to persuade too many people, especially given the cost now for a terabyte of RAM. I’ll just move all of it to an in-memory database before I’ll take on the switching costs.
The thing I wanted was one solution for something that was always two: a properties/metadata database, and a separate time series database.
It seems to me like you are maybe building a level too low and could get a lot more value working on the problem that you say motivated you in the first place. It is hard because of all the context required to automatically detect anomalies, but I think that is why it is valuable to solve.
The value we had was we rolled in the data/cellular connection all the way down to the endpoint, so they could avoid IT integration, which was a big hurdle at the time. I don’t know if IT integration is still a hang up for your customers.
We found that visualization layers tended to reach down just far enough into the data intake world that it was really hard to sell just another tsdb.