4 ms·

> I think you're missing the point about self-hosted db's though - people will not choose to put their data on pushdata.io because their own database cannot han

by eis 8y ago

> I think you're missing the point about self-hosted db's though - people will not choose to put their data on pushdata.io because their own database cannot handle the amount of data they have, but because it is more convenient. Many people, even those who do know a little about databases, do not want to maintain another server [instance] and all that comes with doing that (like backups, for instance). They don't want to set it up, they don't want to maintain or be responsible for it. This choice has nothing to do with performance or size of the data set, but with convenience and peace of mind. I am not so sure. Most projects already need a DB and it's really trivial to store this small amount of data in there as well. I am not sure if it is easier to maintain another account with a third party, write a HTTP POST instead of SQL INSERT and HTTP GET + parsing + processing code instead of SQL SELECT with processing right in the query. One also already needs to do backups of their main data and those backups would just include this timeseries data as well. They most likely don't need another instance, another DB etc. for this amount of data, they just stick it into their existing one. My point being that yes I agree that people reach for third party services out of convenience and not scalability needs BUT this is such a tiny piece of a bigger puzzle that the overhead it comes with might not be worth it. Removing the need to host the timeseries storage part of a product themselves does not remove the need for a DB for 99.99% of projects. If it is trivial to do something myself, then I will do it myself. But if doing it myself takes considerable effort or requires ongoing maintenance overhead, then I might consider a third party service. The higher the value of your service, the better one can make an argument for oneself to use it. E.g. letting people store much more data, letting them process it etc. Points pro using a third party service: 1. Too much time to develop 2. Too much maintenance overhead 3. Too difficult (to scale, develop, ...) 4. Economically unfeasable (because no economy of scale benefit, no synergies etc) Points contra using a third party service: 1. Giving up control over data 2. Legal problems ("where is the data stored?", "am I allowed to hand this data out?") 3. Overhead of interacting with a third party (account maintenance, payments, integration) 4. Inflexibility ("what if I need to change my existing data?", "what if I need some new feature?") As I see it, the points on "pro" don't apply at this scale. See the tiny scale and featureset is not really about data scale but overall "difficulty to do and keep running". If I offer a logging service with a REST API to store and retrieve up to 1000 lines of text without any way to filter/search/aggregate/process, would you use that because it's more convenient or would you just log things to a local file or syslog and call it a day? Like you said it's v1.0 and I'm sure you'll add more stuff, I'm just suggesting that you'll definitely have to add quite a bit of stuff to catch business users. I hope you can make it, I respect everyone who builds a product themselves and tries to make a business out of it. Best of luck!

rlonn 8y ago
I'm not sure you have a DB in all cases. The situation that made me think of this service was such a situation: we (startup business) had no easily accessible db where we could place the data for our fledgling BI project. We were using a Google spreadsheet and entering things manually into it. Things such as new subscriptions and cancels each week, etc. Putting that data into the main user db our SaaS product was using meant disturbing our developers who were very busy and also not to keen on contaminating the production db with BI data :) I think this lack of an existing db is common to many small businesses and hobbyists who are collecting (or want to collect) various forms of time series data, from various sources. You may be right that this is not a service that will attract many business users willing to pay for the higher tiers, that it is more suitable for small- (or tiny-) scale use, but that's the beauty of an MVP - you don't spend too much effort on it and you let the users guide development. If it turns out only serious IoT hobbyists buy, and they only buy the "Personal" subscription, then that's the target audience and the tier to focus on. As for the log file example, sure I would pay someone to store 1000 lines of log data if the data was important to keep. Log files rarely are. But BI data, like new user registrations per day or week is something you never want to lose, and it is not a lot of data. I would pay someone $50/year if it meant I could store some simple BI metrics for my startup, at the resolution I needed, and not have to worry about finding a place in some existing db for it, or set up a new db. Come to think of it, this is another dogfooding opportunity - I have to feed pushdata.io BI metrics into timeseries on pushdata.io! :) Anyway, I hear you and I thank you for the input. You may be right, we will just have to see. I'll be happy whatever target audience I can find that are willing to pay more than it costs me to serve them.

by eis 8y ago

rlonn 8y ago

I'm not sure you have a DB in all cases. The situation that made me think of this service was such a situation: we (startup business) had no easily accessible db where we could place the data for our fledgling BI project. We were using a Google spreadsheet and entering things manually into it. Things such as new subscriptions and cancels each week, etc. Putting that data into the main user db our SaaS product was using meant disturbing our developers who were very busy and also not to keen on contaminating the production db with BI data :) I think this lack of an existing db is common to many small businesses and hobbyists who are collecting (or want to collect) various forms of time series data, from various sources. You may be right that this is not a service that will attract many business users willing to pay for the higher tiers, that it is more suitable for small- (or tiny-) scale use, but that's the beauty of an MVP - you don't spend too much effort on it and you let the users guide development. If it turns out only serious IoT hobbyists buy, and they only buy the "Personal" subscription, then that's the target audience and the tier to focus on. As for the log file example, sure I would pay someone to store 1000 lines of log data if the data was important to keep. Log files rarely are. But BI data, like new user registrations per day or week is something you never want to lose, and it is not a lot of data. I would pay someone $50/year if it meant I could store some simple BI metrics for my startup, at the resolution I needed, and not have to worry about finding a place in some existing db for it, or set up a new db. Come to think of it, this is another dogfooding opportunity - I have to feed pushdata.io BI metrics into timeseries on pushdata.io! :) Anyway, I hear you and I thank you for the input. You may be right, we will just have to see. I'll be happy whatever target audience I can find that are willing to pay more than it costs me to serve them.