I am developing and working on a side project I would like to monetize, RediSQL (RediSQL.com)
The point is that sales are extremely slow.
The software is an SQL database that works on top of Redis (it just use Redis for the connection layer, the data set are completely distinguished) and the SQL engine is implemented by SQLite.
I really believe that there is a market for this, I needed it years ago when developing my own app and people are using it in production (or at least are keeping instance up).
But still I cannot sell it.
I don't understand what I am doing wrong.
I get in touch with users and they are happy and don't ask for features.
I rank extremely high for keyword terms on Google (like "in-memory sql", or "fast SQL engine") and indeed I get an healthy stream of people on the website.
There are things that could be improved in the product, but I don't know what to prioritize.
Moreover I want to avoid to just work in the tech without any marketing... But I don't know what kind of marketing I should do.
I am definitely doing something wrong, but I don't know what.
Please help!
* "Fast": up to 130.000 TPS (inserts apparently) sounds a lot, but I'm not sure it is, see for example http://akorotkov.github.io/blog/2016/05/09/scalability-towar.... Maybe I'm comparing apples with oranges, but since your statement is not backed up by anything I can verify myself this does not stand out as a feature to me. It also sits in a spot where it is too high for startups to be relevant and too low for potential global players since it seems to be the limit, and as you can see in the link, even PostgreSQL provides a way to scale way beyond that number. Maybe your solution can be clustered, but I see no mention of this.
* If I need an in-memory DB, I usually need it for caching or for tests. The first use case is mostly covered by Redis (but I admit being able to use SQL for cache retrieval has some appeal), the second use case (tests) is questionable, since I either use your DB all the way or I'd have a separate DB for tests, which is a not very inviting thing to have to me.
* You state that your DB is not only in-memory only but also can?(is always?) be persisted via Redis. How is that working, what are consequences for conflicts, transactionality etc.? I don't find much about this topic, just a reference that it is "[on] par with incumbent databases such as Postgres or MySQL".
* Lastly, you should mention that the SQL dialect is SQlite. I'd hate having to learn another SQL dialect and I guess many of my peers would do the same.
I'd suggest you switch the focus from "fast in-memory DB" to "Run SQL queries on cached data to allow more leeway to your real SQL database". This sounds appealing to me, provided there are some real-life examples how this can work (e.g. a demo project).
If you go this way, I'd also probably also drop (or not focus) "being able to persist cached data" to automating cache-refreshes consistently, since this would probably be needed.
It sounds to me like you need to find a partner who is into doing that sort of thing. That's what I did. As a bonus, someone who is into this sort of thing likely will be able to give you solid information about how to change your product in order to appeal to a broader audience.
Don't forget the first law of business: be totally honest with yourself about what you can't (or don't want to) do well, and fix that gap by finding people who are good at and enjoy those things.
Also, disregard any opinion that gives feedback on your site or product. Talk to real customers (after reading the book).
"Get in your car" and go see your users instead of sitting at your desk. Seeing is the best way to really understand context and understanding the context in which your customers operate is important for B2B sales. If you can't afford to visit potential customers then it is likely that either the project is under-capitalized or that the project is not economically viable. Under-capitalization and economic viability don't matter for a hobby project. But they matter greatly for a business venture.
How big is the problem? Is it in your potential customers' top 3 pains? Or is this just a nice to have feature for Redis?
> I really believe that there is a market for this, I needed it years ago when developing my own app and people are using it in production (or at least are keeping instance up).
What evidence do you have that a market exists? Do you know how much your users are using the product?
Why would someone buy support from you rather than someone with a track record with a popular database? Do you know what people that make those purchase decisions look for? I'm not going to speculate, since I don't make those decisions, but your post makes it sound like you haven't figured out what you're selling or why someone should buy it from you.