13 comments

  • figassis a day ago

    It's a no for me. I don't want a subscription. Charge whatever you need, give us 1y of updates, charge next year for an upgrade. Do not pull folks into yet another subscription.

    • stevenicr 13 minutes ago

      So glad you posted this comment. Exact thoughts here and you saved me from exploring / wasting time.

    • figassis 7 hours ago

      To add a little bit to this and why I am so principled against this. I will subscribe to a service, because a service means ongoing work. If you spent months or years building software, and have finished it, charge people what you believe is fair for the work you did up to now. Charge $50, charge $500, your call, sell to 1M people, your call. You have no running costs, you're just selling an app.

      If you were running this on some cloud, maybe had some other extras built in that cost you time and money, then there could be a subscription.

      If you want to keep your software updated, and are pushing updates daily, weekly, monthly, etc, I could squint at a subscription, but I would rather you just do critical fixes (bc if your product is broken you do owe paying customers a fix without a charge), and put new features in a new version that you will also sell.

      People are selling git clients, calculators, db clients on subscription. it's crazy what the world has come to. We don't work to pay you guys rent.

      The second I saw this app I was about to click buy (looking for a table plus alternative), went to pricing, saw subscription and immediately dropped it without even trying the free version.

      • upmostly 3 hours ago

        Thanks for taking the time to share your thoughts. We’ve heard this feedback loud and clear from a lot of people, and we completely understand where you’re coming from.

        We’re about to introduce a one time purchase option that includes a full year of updates. No subscription required. This will be available later this coming week.

        Really appreciate you checking out the project and pushing us to make the right call for our users. Stay tuned.

  • metadata 2 days ago

    Hi guys,

    Great to see something fresh in this space. Good luck!

    We are building something fairly similar but haven't launched yet. Competition will make all of us do a better job.

    • upmostly 2 days ago

      Agreed! The more competition, the merrier. Good luck to you guys!

  • etht3x a day ago

    looks very unified and modern, thank you for the effort but have 2 question: 1. do you consider a feature as a carrier of dbt and apply to different db 2. is there a way to cross query between db sorry i know this might went too far

  • atmanactive 2 days ago

    How can I trust this tool not to leak my data to third parties?

    • upmostly a day ago

      We just wouldn't do that in a million years.

      Our goal is to build the best DB client around, and one aspect of that is building trust. We haven't even added user analytics tracking into the product.

      • atmanactive a day ago

        So, if I would connect to a local server on my LAN, my firewall should show zero internet traffic from DB Pro?

        • upmostly a day ago

          Without a doubt, 100%. In fact, you can use it offline if you want. We only make network requests when authorising user accounts. But even then you don't need to create an account. You can just use the free version offline.

  • spicypixel 2 days ago

    Question comes to mind; Why is Postgres supported but neon coming soon?

    • upmostly 2 days ago

      Great question! Postgres is supported right away because it behaves like a standard, direct database connection. But with services like Neon and Supabase, there are extra nuances we want to handle properly.

      We want Neon, Supabase, and similar cloud providers to feel like first-class citizens inside DB Pro and not just “another Postgres connection”. Each of them has their own quirks, authentication flows, and connection requirements. For example, Supabase actually needs a paid IPv4 add-on if you want to connect to it in the traditional way, which isn’t obvious to most users.

      So instead of lumping them in as generic Postgres connections, we’re building dedicated flows that understand these details and make the whole experience seamless. That’s why they’re marked as “coming soon”. We’re doing them properly.

      It all goes back to our UX first philosophy to build the absolute best experience.